C# - Try/Catch Log and Rethrow is a bad practice?

Question

I can see several post where importance of handling exception at central location or at process boundary been emphasized as a good practice rather than littering every code block around try/catch. I strongly believe that most of us understand the importance of it however i see people still ending up with catch-log-rethrow anti pattern mainly because to ease out troubleshooting during any exception, they want to log more context specific information (example : method parameters passed) and the way is to wrap method around try/catch/log/rethrow.

Is there right way to achieve this while still maintaining exception handling good practice ? I heard of AOP framework like PostSharp for this but would like to know if there is any downside or major performance cost associated with these AOP frameworks.

Thanks!!

Answer 1

After little search here and there, I consider answering it myself:

Try/Catch/throw/log littered across methods and code is not a good practice. You should ask below questions when you think of this :

What specifically you going to do with that exception ? If answer is swallow, I would say you need to think twice. If state is corrupted because of swallowing exception in a catch block, then some method higher up in call stack might again throw exception - And now what to do with this exception ? Again same cycle ? It will lead you to a bigger mess soon.

You might sparingly want to follow the pattern of catching exception immediately when you really know you can do something with it (like swallow and retry in case of sql timeout exception) Also you might want to catch exception immediately in case when you want to capture more context specific details in log. In that case catch and re throw new exception wrapping original exception as inner exception.

So in short - its good to have exception handling/logging at application root level or service boundary level.

Having said that - at centralized location you can also configure what to do with specific types of exception. For example :

Bad Request exception thrown as part of data validation in business layer would simply return 400 bad request (in case of web application)

In case exception is of type SqlException - throw generic Exception to client with some tracking ID and log detailed exception to eventlog/db/application insight etc.

In case of any exception from external system in business layer - again send generic exception to client and send notification email to system providing external service.

These are just few examples and good practice around exception handling also implicitly promotes good design. For example: why not to have a safe guard to ensure argument passed to method is not null and throw ArgumentNullException rather than catching NullReferenceException and then capturing arguments value by having try/catch/log at method level.

I posted question around exception handling and logging good practices here. Please check it has good debate and discussion with various suggestions and good practices.