Try-catch best practices

Question

In a N-layer application, what's the right place to have the try-catch block ?
The question is because I've heard that having the try-block from the DAL layer up to UI, could be costly.
Or should I have try-catch in all methods for all layers ?

• UI
• Services
• Repositories
• DAL

Thx

Answer 1

Hi @ANB ,
As far as I think, catch exceptions at the top level and log (or otherwise report) them there, because this is where you have the most information about the the error - most importantly the full stack trace.
There may be some reasons to catch exceptions in other tiers, however:

1. The exception is actually handled. Eg. a connection failed, but the tier re-tries it.
2. The exception is re-thrown with more information (that isn't already available from looking at the stack). Eg. the DAL might report which DB it was trying to connect to, which SqlException wouldn't tell you.
3. The exception is translated into a more general exception that is part of the interface for that tier and may (or may not) be handled higher up. Eg. the DAL may catch connection errors and throw a DatabaseUnavailableException. The BL may ignore this for operations that are not critical or it may let it propogate for those that are. If the BL caught SqlException instead it would be exposed to the implementation details of the DAL. Instead the possibility of throwing DatabaseUnavailableException is part of the interface of the DAL.

Logging the same error at multiple tiers is generally not useful, but I can think of one exception: when a lower tier doesn't know whether a problem is critical or not it can log it as a warning. If a higher tier decides that it is critical it can then log the same problem as an error.

Best regards,
Yijing Sun

---

If the answer is the right solution, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 2

your code should only catch errors it plans on handling. do not use errors for logic

how is your UI code going to recover from errors? what will you tell the user?

depending on the UI needs, errors may need to remapped going up layers. the DAL may be better able to describe a duplicate key error, for instance, Customer already exists message rather than duplicate key.