Hacker News Reader

Comment by Khao | Hacker News Reader

We don't really do catch-all blocks and our app is monitored on New Relic where we almost always have a 0% error rate (rarely we get <1%, most often related to a new commit that we can fix right away)

The only places where we need good exception handling is when doing I/O (network and filesystem). If you have proper layers to handle those things (with queuing/retrying/logging) you end up with a large codebase with very little places where you have to handle exceptions. Anything that is user-input we use TryParse and we do proper validation on the data before doing anything with it. This method is makes it easier to read because you know what the intent is better than doing parse/catch exception in my opinion.

View on HN

Oh, I agree that TryParse is much better than Parse for cases where parsing is expected to fail. But that doesn't detract from having better error handling capabilities in places where it is needed (e.g. i/o). A lot of the .NET i/o APIs will throw 4-5 different types of exceptions, and as the article states, you need to cross reference docs to see which exceptions are possible on certain calls. It's easy to forget or miss because compiler will not care.

You don't need to know the types of exceptions that are possible on certain calls. All you need to know is what exceptions you can handle. They are not strongly related.

The ones you can handle is a subset of possibly thrown ones, which means you need to know the superset before deciding which ones to handle. You're just describing the handling strategy: pass on it or handle it. It doesn't obviate the need to know what's possible there.

As an example, imagine you're building an application that you know uses sockets. And it's in the requirements that your application must be able recover and re-attempt set of operations. So you look into what kinds of network and socket exceptions exist in your platform, framework, and libraries. From there you decide which ones you should trap and attempt to retry.

At no point do you need to know exactly what methods trigger what exceptions. Yes, you do need to know the superset of all exceptions. But that's no different than knowing the superset of all methods or all classes. My point is, a mapping of methods to exceptions is unnecessary.

Interestingly enough, you might end up handling exceptions which can never be triggered by your application. But this isn't a bad thing, as this can make your application more robust in the face of change.

>As an example, imagine you're building an application that you know uses sockets. And it's in the requirements that your application must be able recover and re-attempt set of operations. So you look into what kinds of network and socket exceptions exist in your platform, framework, and libraries. From there you decide which ones you should trap and attempt to retry.

You need to decide where you're going to handle them, and this depends on how much context is required to handle them appropriately. Sometimes this may require doing it right at the point where the method is invoked that triggers the exception. Even if you decide to not handle the exception, you may still want to know the exceptions so you can rollback/adjust state/invariants before letting the exception continue unwinding.

But where you decide to handle an exception is independent of what methods trigger what exceptions. The decision as to where to put error handling code is based on the program structure and requirements. If my requirement is to rollback the current operation and retry, the error handling goes where that operation starts.

I consider adjusting state based on the exception type poor design. That's very tight coupling. But even so, where you put that code is still independent of where exceptions are thrown. If your data state adjustment requires an exception type, check for that where that state change is appropriate. But what methods trigger what exceptions is still irrelevant.

Reply on news.ycombinator.com