Don’t Use Try/Catch (2010)

Unfortunately, "Don't do X" is better click bait than "You should think carefully when you want to do X".

There will be cases where you want to do "catch {}" — you don't always have control over the exceptions thrown by a lower-level library. It might be good to create a standard where you log them conditionally, or something that could aid in troubleshooting.

Not only are the points you raise valid, but I feel the webapp example exemplifies the strengths of exceptions: That the default behavior is to propagate to a context that can deal with the exception, and that you can catch them all at strategic points, like the main request handler of a webserver. You're not "crashing the thread" like the article implies: you're purposefully catching some error you didn't expect (bugs happen), logging/capturing it for debugging (perhaps even with a traceback), and gracefully returning at worst a 500 to the current request, all the while continuing to serve further requests.

It's been best practice for quite some time not to catch { // heh heh he. }.

How do you feel about Erlang?

Ah, it was people like you who did this even when, as you said it should never happen, that caused me many a late night... 'cause it did and that empty catch block hid it.

Don't leave empty catch blocks. At least put in some form of logging of the exception, just in case.

The most common code I write in C# is in switches on enums:

   default:
     throw new InvalidOperationException("Should never happen!");

My thought would be to add an assertion that always fails inside the catch block, but this probably only makes sense if you use assertions already, as they have to be turned on explicitly in Java.

Years ago I found the source of my troubles which took longer than it should have because Tomcat had an empty catch around InterruptedException with a "this will never happen" comment.

Why don't you just throw a runtime exception inside the catch block?

Unfortunately yeah - sometimes the brokenness of tr/catch you inherit from the platform level.

Reminds me of when I was trying to write a Win8/Metro app for fun. Turns out in the particular network class I was using 404's throw exceptions. What a horrific design - 404 isn't an unexpected state at all, particularly when calling restful apis. But there we were, a pointless try/catch or nothing.

A lot of the brokenness with exceptions is software that models expected operational state as exceptions.

Due to asynchronous nature of JavaScript it's basically impossible to use "one big try/catch". Code that is invoked via setTimeout executes with an empty stack so something like

try { setTimeout(foo, 1000) } catch (ex) { ... }

won't be caught here if foo throws. In some DOM APIs there are 'onerror' handlers (like XHR), in NodeJS the convention is to have an "error" first parameter in the callback (which is null if there's no error).

Also try-catch generates additional scope object inside the catch clause hence it's a bit more expensive than just doing a function call.

Generally try-catch makes sense in JavaScript only locally when executing some external synchronous code that is known to throw exceptions.

Please, don't even think about such approach if you handle many long-living tasks (like, say, client connections) in a single OS-level unit of execution (process or thread) and the error/exception happens for a single task but crashes the whole stack.

Please use some restraint! Sometimes an exception is not the answer!

I've had... I think it was Windows::UI::Input::PointerPoint::GetCurrentPoint throw exceptions if the finger passed in was no longer touching the screen. Sounds fine at first, right? Except...

1) This occurred before "finger released" events, so you'd run into a crash because they thought throwing an exception was better than returning the last known finger position, which would've rightly left me with no error report.

2) This occurred in a nasty rare corner case, making figuring out the reproduction a PITA. I don't think I'm alone in not expecting such a simple function to throw when given a known-to-me-valid fingerId. Worse, the exception was completely undocumented on MSDN -- either explicitly or as a hint from function signature (at least Win32 had the common decency to return BOOL or HRESULT.)

3) I found no method for validating a finger ID, so one had to simply catch the exception and accept the massive framerate dip of exception handling overhead if the user pawed at the screen. Before you mistake that for hyperbolic performance concerns: I could make a smooth 30fps tank to bellow 10fps consistently. I measured!

Touch input isn't the only unexpected thing throwing exceptions for WinRT. The end result of this "throw exceptions whenever you can" mentality is I've been forced to build a habit of wrapping every WinRT API call in extremely wide try/catch blocks to log whatever random undocumented exceptions come crawling out of it. By becoming the rule, it took the "exception" out of "exceptions". I'm sure you'll agree: This is horrifically ugly, slow, and in generally poor taste.

But it's necessary. The other alternative is you hopefully find as many as 90% of the weird junk that crashes your program with exceptions, most of which you don't actually care about in the slightest -- and the other 10% avoid discovery and instead explode your stuff in production, most of which will be for no good reason.

Python 3.3 fixes this, by implementing PEP 415¹, which keeps the original exception available by using this syntax:

  except SomeException as exception:
    raise NewException("stuff happened") from exception

1) http://www.python.org/dev/peps/pep-0415/