We have some logic for displaying custom error pages in our ASP.NET application through overriding Page.OnError. Now, when an error occurs within that error handling routine I can redirect somewhere else using the in web.config.
This works for most errors. Yet, I cannot find how to display a custom error page (or anything at all!) when getting e.g. a StackOverflowException. Obviously I cannot do any more processing insode ASP in such a case as practically anything will result in some allocation on the stack. The same is probably true for OutOfMemory, though I have not found any sensible way to test this. Is there any possibility I could still display something (possibly static) to the user, e.g. directly from IIS instead from ASP?
Related
I had some custom error handling code in Application_Error, which was doing some logging and then handing off to my Error controller action/view. I had a bizarre issue where sometimes - and only on my production server, not on my development machine - the error page would appear, but no error details were recorded in the log.
I spent several hours trying to figure this out, and it turns out that my error page was being invoked directly, without going through Application_Error!
I saw a throwaway comment on another SO post that implied that this might happen with the HandleError attribute - i.e. that it would look for a view called Error, and simply render that, bypassing Application_Error.
I was using Elmah.MVC, and so did not explicitly use the HandleError attribute, because Elmah does this for you. However, it turns out that Elmah also does the straight-to-error-view thing too, because when I renamed my view (and controller action) to something else, everything started working as expected.
Just posting this in case it helps someone else...
When I purposefully throw a php error from within embedded php code in the php filter module, Drupal displays the message The website encountered an unexpected error. Please try again later.
We like to send users with unanticipated programmer errors to an error handling page so that they don't land on a dead error page without us getting notified, so I'm trying to find out how to intercept this in Drupal. I've tried searching within Drupal for where this error string gets outputted, with no luck.
How exactly does Drupal handle errors occurring within embedded php code, or more directly: how can I make it redirect to another page or catch the error in another way?
Thanks
That specific error comes as a result of Drupal explicitly setting the PHP exception handler to a custom function (done in _drupal_bootstrap_configuration()).
The exception handler itself is _drupal_exception_handler(), which invokes _drupal_log_error(), and that's where the error page is generated.
I've never tried it, but I reckon you'd get away with implementing hook_boot() and using set_exception_handler() to provide your own implementation of the core Drupal functions to theme that error page differently.
It might seem a bit of a long way round but since _drupal_error_log() doesn't invoke any hooks (it probably happens too early on for that anyway) I can't see any other way to do it without editing the core files.
I have a few sites in my IIS including ASP.Net and PHP. I want to define a custom pages for error handling that I can configure in IIS and it displays on errors occuring in all the sites. Say for example if error 500 is occured it displays an ASP.Net page having detailed error info of what happened actually. Is that possible?
No. = (
PHP
For your PHP sites, there are different solutions including error-logging plugins, but the standard one involves the built-in functionality of PHP's error handling. See here: http://www.nyphp.org/PHundamentals/7_PHP-Error-Handling
ASP.NET
For ASP.NET sites, this is the default behavior of the IIS error page. It will show you the exact error code, stack trace, and offending lines of code. If you wanted to, you could create your own application-level error handler to handle any and all exceptions that can occur inside your site; usually this is used to hide the nasty error message and show the user a friendlier, less-scary message instead. You can certainly re-use the code in all your different ASP.NET sites. See: http://www.codeproject.com/Articles/5977/Global-Error-Handling-in-ASP-NET
We're having an issue with a .NET 3.5 WebForms site where occasionally our error logs start filling up with the following error message:
"Multiple controls with the same ID 'ctl09' were found. FindControl requires that controls have unique IDs."
I know very little about the exception as I have never seen it while debugging locally and have never caught it in the error logs soon enough to run a remote debugging session. I do know that an application pool recycle fixes the issue.
This only affects a single [high traffic] page in the site. The strange thing is that the site uses the pre-4.0 ID generation logic. So, when the page is working, there isn't an html element in the entire view source that isn't some autogenerated control ID prefix followed by a the 'actual' IDs (i.e. ctl09_someID_someOtherID).
So, 2 primary questions, though any ideas are welcome:
What would case a control to randomly stop being built correctly?
Other than the Global.asax, how can I trap this error and force the control to ... recompile? App pool to recycle?
I'm pretty much stumped.
Nothing as far as I'm aware, only an outside entity interferring with the page lifecycle or AJAX postback could potentially cause this, if each control is being generated, in turn, then you will not 'randomly' experience duplicate ids.
I don't think this is a viable option, app pool recycle? No way, there's got to be a valid reason for this.
Perhaps some more info/code would be useful? Is it a particular page? Are you using ViewState? There's lots of reasons for 'dodgy' control ids.
I am relatively new to ASP.NET programming, and web programming in general. We have a site we recently ported from .NET 1.1 to 3.5. Currently we have two methods of error handling: either catching the error during data load on a page and displaying the formatted error in a label on the page, or redirecting to a generic error page. Both of these are somewhat annoying, as right now I'm trying to redesign how our errors are displayed.
We are soon moving to Master pages, and I'm wondering if there is a way to "build in" an error handling control. What I mean by this is using a ASP.NET user control I've designed that simply gets passed the error string returned from the server. If an error occurs, the page would not display the content, and instead display the error control. This provides us with the ability to retain the current banner/navigation during an error (which we don't get with the generic error page), as well as keeping me from having to add the control to every aspx page we have (which I have to do with using the label-per-page system). Does something like this make sense? Ultimately I just want to have the error control added to a single page, and all other pages have access to it directly. Is this something Master pages help with?
Thanks!
User the application_error event in the global.asax to catch all your unhandled errors - you can log them here. You shouldn't be outputting error messages to the client like this.
Use the CustomErrors section in the web.config to define a custom error page for your users to get.
You could also look at using something like ELMAH for easy loggin.