<p>I admit it: I don't bother with too much exception handling. I know I should do more but I can never wrap my head around where to start and where to stop.  I'm not being lazy.  Far from it.  It's that I'm overwrought with exception handling ambivalence.  It just seems that there is a seemingly infinite number of places in even the smallest app where exception handling can be applied and it can begin to feel like overkill.</p>

<p>I've gotten by with careful testing, validating, and silent prayer but this is a bad programming accident waiting to happen.</p>

<p>So, what are your exception handling best practices?  In particular, where are the most obvious/critical places where exception handling should be applied and where are places where it should be considered?</p>

<p>Sorry for the vague the question but I really want to close the book on this once and for all.  </p>

[{'answer_id': 55969, 'author': 'aku', 'author_id': 1196, 'author_profile': 'https://Stackoverflow.com/users/1196', 'pm_score': 5, 'selected': True, 'text': '<p>Microsoft\'s <a href="http://msdn.microsoft.com/en-us/practices/default.aspx" rel="nofollow noreferrer">Patterns &amp; Practices team</a> did a good job incorporating best practices of exception management into Enterprise Library <a href="http://msdn.microsoft.com/en-us/library/cc511522.aspx" rel="nofollow noreferrer">Exception Handling Application Block</a></p>\n\n<p>Event if wouldn\'t use Enterprise Library, I <em>highly</em> recommend you to read their documentation. P&amp;P team describes common scenarios and best practices for exceptions handling.</p>\n\n<p>To get you started I recommend read following articles:</p>\n\n<ul>\n<li><a href="http://msdn.microsoft.com/en-us/library/ms229005.aspx" rel="nofollow noreferrer">Exception Handling</a> on MSDN</li>\n<li><a href="http://msdn.microsoft.com/en-us/library/ms229005.aspx" rel="nofollow noreferrer">Exception Management in .NET</a> on MSDN</li>\n<li><a href="http://www.codeproject.com/KB/architecture/exceptionbestpractices.aspx" rel="nofollow noreferrer">Exception Handling Best Practices in .NET</a> on CodeProject</li>\n</ul>\n\n<p>ASP.NET specific articles:</p>\n\n<ul>\n<li><a href="http://www.codeproject.com/KB/aspnet/ASPNETExceptionHandling.aspx" rel="nofollow noreferrer">User Friendly ASP.NET Exception Handling</a></li>\n<li><a href="http://www.developer.com/net/asp/article.php/961301" rel="nofollow noreferrer">Global Exception Handling with\nASP.NET</a></li>\n<li><a href="http://www.codersource.net/asp_net_exception_handling.aspx" rel="nofollow noreferrer">Exception handling in C# and ASP\n.Net</a></li>\n</ul>\n'}, {'answer_id': 55970, 'author': 'samjudson', 'author_id': 1908, 'author_profile': 'https://Stackoverflow.com/users/1908', 'pm_score': 0, 'selected': False, 'text': '<p>Well at the very basic level you should be handling the HttpApplication.Error event in the Global.asax file. This should log any exception that occurs to a single place so you can review the stack trace of the exception.</p>\n\n<p>Apart from this basic level you should ideally be handling exceptions where you know you can recover from them - for example if you expect a file might be locked then handling the IOException and reporting the error back to the user would be a good idea.</p>\n'}, {'answer_id': 55975, 'author': 'Magnus Akselvoll', 'author_id': 4683, 'author_profile': 'https://Stackoverflow.com/users/4683', 'pm_score': 2, 'selected': False, 'text': '<p>I recommend you start by adding a good error page that catches all exceptions and prints a slightly less unfriendly message to the user. Be sure to log all details available of the exception and revise that. Let the user know that you have done this, and give him a link back to a page that will (probably) work.</p>\n\n<p>Now, use that log to detect where special exception handling should be put in place. Remember that there is no use in catching an exception unless you plan to do something with it. If you have the above page in place, there is no use in catching database exceptions individually on all db operations, unless you have some specific way to recover at that specific point.</p>\n\n<p>Remember: The only thing worse than not catching exceptions, is catching them and not doing nothing. This will only hide the real problems.</p>\n'}, {'answer_id': 55983, 'author': 'Wheelie', 'author_id': 1131, 'author_profile': 'https://Stackoverflow.com/users/1131', 'pm_score': 3, 'selected': False, 'text': '<p>The golden rule with exception handling is:</p>\n\n<blockquote>\n  <p>"Only catch what you know how to handle"</p>\n</blockquote>\n\n<p>I\'ve seen too many try-catch blocks where the catch does nothing but rethrow the exception. This adds no value. Just because you call a method that has the potential to throw an exception doesn\'t mean you have to deal with the possible exception in the calling code. It is often perfectly acceptable to let exceptions propagate up the call stack to some other code that does know what to do.\nIn some cases, it is valid to let exceptions propagate all the way up to the user interface layer then catch and display the message to the user. It might be that no code is best-placed to know how to handle the situation and the user must decide the course of action.</p>\n'}, {'answer_id': 55985, 'author': 'Ash', 'author_id': 5023, 'author_profile': 'https://Stackoverflow.com/users/5023', 'pm_score': 1, 'selected': False, 'text': '<p>Might be more about exception handling in general than ASP.NET speific but:</p>\n\n<ul>\n<li>Try to catch exceptions as close to\nthe cause as possible so that you\ncan record (log) as much information\nabout the exception as possible.</li>\n<li>Include some form of catch all, last\nresort exception handler at the\nentry points to your program.  In\nASP.NET this could be the\nApplication level error handler. </li>\n<li>If you don\'t know how to "correctly" handle an exception let it bubble up to the catch all handler where you can treat it as an "unexpected" exception.   </li>\n<li>Use the Try***** methods in .NET\nfor things like accessing a\nDictionary.  This helps avoid major\nperformance problems (exception\nhandling is relatively slow) if you\nthrow multiple exceptions in say a\nloop.</li>\n<li>Don\'t use exception handling to\ncontrol normal logic of your\nprogram, e.g. exiting from a loop via\na throw statement.</li>\n</ul>\n'}, {'answer_id': 230622, 'author': 'Todd Smith', 'author_id': 30885, 'author_profile': 'https://Stackoverflow.com/users/30885', 'pm_score': 1, 'selected': False, 'text': '<p>Start off with a global exception handler such as <a href="http://code.google.com/p/elmah/" rel="nofollow noreferrer">http://code.google.com/p/elmah/</a>.</p>\n\n<p>Then the question comes down to what kind of application are you writting and what kind of user experience do you need to provide. The more rich the user experience the better exception handling you\'ll want to provide.</p>\n\n<p>As an example consider a photo hosting site which has disk quotas, filesize limits, image dimension limits, etc. For each error you could simply return "An error has occured. Please try again". Or you could get into detailed error handling:</p>\n\n<ul>\n<li>"Your file is to large. Maximum\nfilesizes is 5mb." </li>\n<li>"Your image is is\nto large. Maximum dimensions are\n1200x1200." </li>\n<li>"Your album is full.\nMaximum storage capacity is 1gb".</li>\n<li>"There was an error with your\nupload. Our hampsters are unhappy.\nPlease come back later."</li>\n</ul>\n\n<p>etc. etc.</p>\n\n<p>There is no one size fits all for exception handling.</p>\n'}]
['https://Stackoverflow.com/questions/55961', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/3742/']