Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I in general agree w/ David and Peter... The one thing I would add is to be careful about exceptions you catch when you catch them... <a href="http://rads.stackoverflow.com/amzn/click/0735627045" rel="nofollow">Richter</a> has a very interesting chapter on exception handling and how exceptions were SUPPOSED to be inherited versus how they have actually been implemented... But even still, it's (IMO) lazy or at least ill-thought-out if you find yourself consistently catching the generic Exception class... </p> <p>If you're doing file reading/writing, you may very well want to catch appropriate IO exceptions, but to consistently catch the most generic Exception class can lead you to problems if say, a NullReferenceException gets thrown and your try/catch was only protecting against IO Exceptions... Your catch block would try to fix (what it assumed was) an IO exception and it could put your code in a horribly unstable state.</p> <p>Additionally, be very careful about continuing to re-throw the original error unless you're convinced you TRULY handled it appropriately... If you wrote a library and published it and swallowed all the errors because you thought you were doing the best thing, then someone that consumed your library would have no way to debug what was going on... Exceptions also get thrown into the servers logs, so a swallowed error would never make it there.</p> <p>The one place that I would advocate catching the generic error is right at the UI layer where you obviously don't want to show the user a YSOD, but even then your catch should likely do some logging or something to help you debug later.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload