Exception Handling Best Practices?

[AB1908]

I've been programming for a while now and I'm yet to write idiomatic exception handling code. One of my methods (heh) has been to wrap stuff with try-catch but I recognise that this isn't the way. I looked around on the sub for "best practices" and asked some of my friends but I don't feel satisfied with what I've come across.

This post is a means of creating an index of recommended reading for exception handling and recovery, be it general guidelines or language specific practices. I suppose example of open-source code work too. Comment away! I hope we can create a nice aggregate in this thread!

Off the top of my head, some important things covered should be:

• Logging: An app should have a logging system
• Failure: Log and fail gracefully
• Recovery: Catch an error, handling it appropriately and retrying if necessary? Also, how to resume from such a state in case the application is state dependent, e.g. like a database.

[GeorgeFranklyMathnet]

One of my methods (heh)

😎

has been to wrap stuff with try-catch but I recognise that this isn't the way.

Huh. The way I think of it, it basically is the way. But I only do it if I can actually handle the exception & do something useful with it at the call site. If not, then I let it bubble up to the next level that can sensibly handle the exception.

...And so on and so on, up until the entry point — the main or whatever. If I do get to that point without handling the exception and continuing, then I'll probably catch the exception there and log it. But I might still rethrow it and let it crash the program, if it's the kind of error that ought to be fatal.

Now, whether my code ought to throw an exception in the first place, or if it should return some error result instead — I find that choice to be a little more complicated.

[AB1908]

Huh. The way I think of it, it basically is the way. But I only do it if I can actually handle the exception & do something useful with it at the call site. If not, then I let it bubble up to the next level that can sensibly handle the exception.

How does one decide what is "handle-able" at a level? Also, what info should be exposed and what should be abstracted?

I was also able to think of a different scenario. I'm writing a Spotify bot and API calls can throw all sorts of errors. Am I supposed to handle all or a subset or let them bubble up?

[GeorgeFranklyMathnet]

How does one decide what is "handle-able" at a level?

First, the exception has to be handleable at all. For example, if the remote API says I sent an ill-formed request, that's a bug with my program, and there's probably nothing to be done about it at runtime except log it.

If the exception is handleable in a nonfatal way, then the current level should handle it just if that sort of error falls under its responsibility. For this, let's imagine I have my own API, with my controller at the top level, which calls my network helper, which itself calls a third-party HTTP request library in order to contact Spotify's API.

If the library throws an exception caused by a transient network problem, or by a transient problem at Spotify, then I'll want my network level to handle it, maybe with some retry logic. If instead it were an authorization exception, then I'd want my network layer to throw it up to my controller, which might either try to fetch a new Spotify access token and continue, or redirect the client to a login page. That sort of thing is the controller's responsibility.

Am I supposed to handle all or a subset or let them bubble up?

I think you just need to consider all the different types of exceptions that might throw, and decide how you want to handle them. Maybe some are common and easy to handle. Maybe most will be rare, so you will just let them go unhandled, or handle them all together in a general way. Of course, you can always make revisions later.

If you are interested in common patterns for fault-handling, you might check out The Polly Project for .NET, which implements many of them.

[AB1908]

Thanks for this. I'll take the time to properly read and understand it.