Lets say I have a web app, and despite my best testing efforts, several of the many thousands of people who uses it will find some way to generate an exception. Sure, I have error handling code for my classes and methods.
But, being unable to anticipate the context and effects of a creatively-caused exception, should I wrap the entire “main controller” in a try-catch block and just do something like echo an apologetic error page, rather than silently dying (or worse still, echoing the error string to the user)? What is correct programming practice regarding unexpected error-handling like this?
There’s no “etiquette,” other than possibly the “principle of least surprise.” The solution depends on your software’s functional requirements. What behaviour does your requirements specification say it should exhibit when an unexpected exception is thrown?
If I were designing the application, I would provide a high-level exception handler that can capture the stack trace and other relevant information in a log, so that I can do some forensic analysis and provide a possible fix. Depending on the actual problem, the solution might be to trap that particular exception and take some action like redirecting to the Login page, rather than showing an error page.
Stack Exchange provides a “something bad happened, but we already know about it, and our unicorn overlords are already feverishly isolating the problem” page to the user, when an unrecognized error occurs.
Creating your own 500 error page is usually better than whatever the default behaviour is for your technology. When the 500 error page shares the same styling with the rest of your site, its clear to the user that they are still on your site and provides them with navigation links so that they have some options for what to do next rather than pressing the browser back button or the X button.