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:
Related
I have a global error handling for the controller which is working fine. But sometimes when any web.config element are missing or can't able to load it shows the error screen and hitting the application-error in the global.asax as the the exception never reaches the pipe line. Also I was able to redirect to a custom error page by setting custom error as remoteonly with redirection page but not able to log it as not hitting application-error in global.asax. Does anyone know how to handle the exception here
I guess, Exception handles your code only, the exception which you were taking is before any code to be execute and it will handle by Web Server i.e. IIS
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 have a global error handler in Global.asax and am trying to display the exception information in a page called ErrorPage.aspx. I've read Microsoft's page about passing information between asp.net pages (http://msdn.microsoft.com/en-us/library/6c3yckfw.aspx). I don't think any of these will work:
QueryString: I'm concerned that the length of the exception will
exceed the maximum length of the QueryString.
Post Information: The Global.asax page doesn't have any form fields.
Session State: Session state is not available in Global.asax
Public Values: I think this only works with .aspx pages
Control from Source Page: Global.asax can't have asp.net controls.
My current thought is that it would be logical to create an instance of the ErrorPage object and navigate to it (as you could do in a Windows Forms application), but I don't know how to do that or if it is possible in asp.net.
Ultimately, I'm looking for a way to display errors caught by a global error handler in a standard .aspx page. Any suggestions would be helpful.
What I would do:
Log exception information including stack trace in a log file,
Redirect to an ErrorPage with error code (regular http errorcodes + a generic 'unknown error' one + maybe some custom errors that make sense for the application) passed in query string parameter,
Display a predefined message for this error code.
There is little reason to display actual error messages to end users, more detailed error information not withstanding. If you want to display full information for debugging purposes, turn custom errors off in web.config
Code snippet..
if (regionalApprover == null)
{
throw new Exception(string.Format("The regional approver for {0} could not be found", companyData["Country"]));
}
How does the user actually see this error ?
The result of an unhandled exception depends on a variety of factors, including
where the web request is coming from,
the settings of the <customErrors> Element in your web.config and
the contents of Application_Error in your global.asax codebehind file.
In the default configuration, IIS will log the error into the Windows event log. In addition, it is shown in the browser by ASP.NET if the web request comes from localhost.
If you're trying to display an error message on the page (that the user is supposed to see), don't use Exceptions.
It's a much better idea to add an errors section to the page that you can add the messages to before showing the page to the user.
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.