Exception handling practices top level vs every function

Question

I've seen several approaches of exception handling. Two most common patterns I've seen are:

• try catch on every function, log the exception and rethrow
• try catch on the top most level (Like main function), log the exception and rethrow

Which is a better practice if there is one? Or what situations would you choose one approach over the another?

Answer 1

I don't see a huge difference in Logging and rethrowing an exception in the lower stack. So just rethrowing for logging seems wasted exception handling. This might be useful if you're doing something meaningful (need to cleanup stuff, throw a new domain exception or do a second try before throwing).

But logging the exception itself can be done on highest level easily.

Answer 2

This depends on your application and is a design choice, though option 1 is very messy. You should only catch exceptions you are prepared to handle in someway, not arbitrarily catching every one. In most languages the exception will have a stack trace for you to look at so logging at every level is unnecessary. When I say handle in some way that may be to log and rethrow, or it may be to log, notify the user of some error, and continue to run

As a side note, you should not be using exceptions as logic in your code. If you find yourself using try catch blocks as flow control then you should think of a redesign. Exceptions are just that, exceptional.

Answer 3

Option 1 is considered as bad practice and should be avoided, and option 2 is the best practice which you should follow.

Principle of exception handling is by default let exceptions throw naturally and catch them on the top level like option 2. Just only one case you should catch exception is you want to do some business logic based on exceptions. If you don't process business logic, don't catch.

More cons of option 1:

1. Lots of try-catch and re-throw makes your code less readable,

2. Think about catching exceptions in every methods and log them will make log file log the same exception info which is not necessary.

Answer 4

The practice I have seen most of the time is:

Catch those exceptions which you are ready to handle. For example, Insertion of duplicate primary key, catch it, and display an appropriate message to the user for entering something unique for the record.

For rest of the application, there will be no exception handling at libraries. So that if an exception occur it may get pop to the upper layer, where appropriate handling may be done.

You may see this article: Exception Handling Best Practices in .NET

Answer 5

I would usually avoid option 1 completely because i dont see the value of really logging every function that the exception passed through. You are mainly concerned usually about the place where the exception happened. There might be a case for knowing the exact flow as to how it got there but you can get that from the exceptions call stack.

The principle I use for handling exceptions is to catch them only if i am doing something with it. If the only purpose of catch is to rethrow, then there is no point in catching it. However, if i do catch it, and then log it / wrap it with a custom specific exception / handle it for example, thats a good enough reason. I usually find that such tasks are not done in every function but most commonly at layer / tier boundaries