I have a web user control which my aspx page contains. During testing I discovered a exception being thrown. (The general rule that is in place, is that when an exception occurs the user is redirected to a excpetion page detailing the error)
Once the excpetion was handled in my User Control I wanted to throw it to the page where the parsing and redirect could occur safely. I do this in other circumstances by using the Global Asax, Application_Error to deal with the redirect etc. however all that happened when I threw the exception from the user contorl was I got a horrible javascript type dialog with the exception message.
To work around this I declared an Event which is then raised from the user control with the exception as the parameter. I can successfully parse the expception to the required format and redirect the user to the exception page.
My question(s) are these
Why does throwing the exception from the user control only result in the javascript dialog and not the Global.asax error
handling kicking in.
Is there a
way to force consumers of the
control to handle my custom error
event? Simialr to a "MustImplement" -----a "MustHandle" kind of affair?
Why does throwing the exception from the user control only result in
the javascript dialog and not the
Global.asax error handling kicking in.
Because there is a page error during an asynchronous postback, here's a good article on Error Handling in ASP.Net Ajax Applications.
2.Is there a way to force consumers of the control to handle my custom error
event? Simialr to a "MustImplement"
-----a "MustHandle" kind of affair?
This explains how to handle asynchronous postback errors in the Global.asax.
I'm not versed in ASP.NET but I'll give it a shot:
Why does throwing the exception from the user control only result in the javascript dialog and not the Global.asax error handling kicking in.
The error is raised on the client side, your error handling takes place on the server side. Unless you implement an AJAX-y callback that kicks in upon errors, the server isn't notified of any client-side errors. This doesn't seem to be the default behaviour in ASP.NET. You might check out Microsoft's AJAX library, surely they already have a mechanism for such things in place.
Is there a way to force consumers of the control to handle my custom error event? Simialr to a "MustImplement" -----a "MustHandle" kind of affair?
Simple answer: no.
Related
I want to handle all uncaught exceptions in my ASP.NET application. I want to display a custom UI to the user, but NOT redirect them (so the URL would be the original URL which produced the exception). I also have ELMAH which is configured by the end-user (well, end-administrator really, but not me). Elmah attaches a handler to the Application.Error event and does it's logging there.
I now have two possible places to handle the error and generate the output Application_Error and Application_EndRequest. The logical place would be Application_Error, but that has two problems:
If I don't remove the exception with ClearError(), ASP.NET will replace my output with it's own default output.
But if I do remove it with ClearError(), then ELMAH might not get the exception because the event handler execution order is undefined.
I checked that the error still persists in Application_EndRequest so I could do it there, but that feels kinda.... wrong. Can I get into trouble by doing this?
I have a webform that has a single page method. My other web apps log unhandled exceptions to the system event log on the web server. Since the other developers that I work with expect to see entries for app errors in the event log, I would like this app to do the same.
However, I have the app send error emails when an exception is caught from calling code inside the page method. It is not writing to the event log when this occurs. Note: the page method re-throws the exception after calling my email notification method.
From what I've read so far it seems that ASP.Net logs errors to the event log by default. I imagine that the same is not true for Page Methods/WebMethods because they basically throw the exception to the client code calling it.
Is there a trivial way to have that exception bubble up properly so that it writes to the event log? No other apps write to the event log directly from what I've seen so I don't think the application could create a new source since our security people keep a lot of things locked down (with good intentions, yay security).
[WebMethod]
public static object MyPseudoWebMethod()
{
try
{
// My exception spawning unreliable code here
}
catch(Exception ex)
{
// Cleanup ...
this.SendErrorNotification(ex);
throw; // <-- This doesn't bubble up but I'd love for it to!
}
}
Hmm interesting problem. You are right in that WebMethod exceptions do NOT follow normal exception flow.
The Application_Error event is not fired if your web method throws an
exception. The reason for this is that the HTTP handler for XML Web
services consumes any exception that occurs while an XML Web service
is executing and turns it into a SOAP fault prior to the
Application_Error event is called.
(from here)
The above page suggests using a SOAP extension to catch that exception before its swallowed, but here's how I'd do it if you don't want to do that:
1) Make a new 'error recieving' ASPX page that you will build that will take whatever params you want to record in your error log. So for example, have this page take in a POST named "ExceptionDetails" or whatever else you wish to capture. This page will NOT be viewed directly in a browser, so it doesnt need any ASPX controls or anything, but using a MasterPage on it won't hurt anything.
2) In the code behind of this new page, grab whatever POSTS you are sending in and new-up an Exception with whatever details you need. Immediate throw this exception. Doing this means that this exception will follow whatever flow other unhandled exceptions follow in the app (logging, emailing, etc).
3) On the page that calls the WebMethod JS, Wrap the calls to the WebMethod in a try-catch
4) In the catch block, print out whatever message you want in the browser, and initiate a new AJAX post to that new error receiving ASPX page, passing along whatever POST stuff you made that page look for.
The new AJAX call will NOT change ANYTHING in the user's perception by default. The AJAX call fires off a new request to that page, and the ASPX page itself is actually totally unaware that its AJAX and not a normal browser request. Any cookies/session/authentication data that's currently set are available to the AJAXed page as well, if you are recording a user's ID or anything. If you look at the returned response from a tool like Firebug, you will see that its actually the YellowScreenOfDeath's HTML (unless you have a custom 500 page, in which case its that HTML that comes back).
This is simply how the legacy ASMX web services work.
The only workaround is to stop using them (which you should do anyway, unless you're stuck with .NET 2.0). WCF doesn't have this problem.
I am developing an web application on Azure, on occurrence of exception I want to display an error message to the User on a custom error page.
What is the best practice, I don't want to use Session to store the Exception.
Currently, I am using Azure diagnostics to log the error in Logs Table and Events Table and Session to Store the exception detail under Global.asax.cs (app_error) event
And using the Session in Error page to display the error.
Sorry the question is much of basic..any inputs would be helpful..
Do you mean you’re using a custom ASP.NET error page? In this case, you can use HttpServerUtility.GetLastError to get the exception. Refer to http://msdn.microsoft.com/en-us/library/system.web.httpserverutility.getlasterror.aspx for a sample.
Same thread from you in MSDN forum: http://social.msdn.microsoft.com/Forums/en-US/windowsazuredevelopment/thread/df31d683-81a9-4527-9109-94e57ff528f1
Based on what you have provide, I am sure you are developing an ASP.NET Web Role and want to display custom error page in an event of exception. You can use ASP.NET Built in Custom Error Page functionality to display custom error page with hand crafted exception details and message on it.
At Page Level you can use the Page_Error event handler by implementing the Page_Error method on all of your pages.
At Application Level, you can use Application_Error handler to trap exceptions/errors by defining Application_Error method in Global.asax page.
At Global Level, you can handle exceptions/errors by adding custom errors setting in web.config as below:
I'm using the common practice of catching errors in global.asax in my ASP.net application. In global.asax, I have a function Application_Error that logs the errors to the database.
This works very well to log errors that occur when the user requests a page.
However, this does nothing to help when an asynchronous method (a method decorated with the [WebMethod] attribute) called from the client-side throws an exception. The exception simply bubbles up and may be returned to the client-side code, but I would like to have the error handling code run on the server automatically similar to how page errors are logged in global.asax.
How do I accomplish this? One way would be to wrap every single asynchronous method with try-catch, but this doesn't seem like a good solution to me.
One option is to create an ASP.NET output filter that intercepts and logs WebMethod exceptions sent by ASP.NET to the client. Here's the basic idea:
Create a subclass of Stream that captures the content of the response.
When the stream is closed, check whether the response has a 500 status code as well as a "jsonerror: true" header. If so, the response contains a WebMethod exception; log the exception.
In Global.Application_PostMapRequestHandler, install an instance of this class as the output filter for JSON requests.
For complete source code, see this StackOverflow answer.
How to create a global exception handler for a Web Service
In the Application_Error method in Global.asax I am trying to retrieve a value from session state.
I am able to access session state as long as I throw the exception. EG:
thow new Exception("Test exception");
However if it is an unhandled exception, i get the following error when trying to access session state: "Session state is not available in this context.".
Why the differences in behavior, is there a work around?
Thanks.
I hate ASP.NET sometimes...
So generating an error using:
Response.Redirect("thispagedoesnotexist.aspx", false);
The above line will redirect to Application_Error with session state not available
However
throw new Exception("test");
The above line will redirect to Application_Error with session state AVAILABLE
So instead of doing this all in Application_Error, in one spot, I will have to use try/catches through out my code to catch errors. Then gather data from session, log and email error details, then finally redirect to friendly error page. Lots of extra code..
Conclusion: Application_Error is worthless.
I think you are trying to access the session through HttpContext.Current.Session. I believe the difference in behavior is that in the unhanded exception handler, the request has gone into "Failsafe" mode and the page lifecycle (including loading and disposing the session) has finished.
Check out this page on the lifecycle for more info