Should i rethrow exception

Instead, it will be propagated up the stack to the caller. Although this works, this method has a couple of downsides. Although the compiler is free to elide the copy, it may not, so this could be less performant. In this case, getIntValue throws a Derived object, but the catch block is catching a Base reference.

This is fine, as we know we can have a Base reference to a Derived object. However, when we throw exception, the thrown exception is copy-initialized from variable exception.

Variable exception has type Base, so the copy-initialized exception also has type Base not Derived! In other words, our Derived object has been sliced!

The fact that the second line indicates that Base is actually a Base rather than a Derived proves that the Derived object was sliced. You could, for example, make a method call to validate a condition. The only requirement is that the expression is a predicate—it returns a Boolean value. In other words, you can essentially execute any code you like from within the catch exception call chain. This opens up the possibility of never again catching and rethrowing the same exception again; essentially, you're able to narrow down the context sufficiently before catching the exception as to only catch it when doing so is valid.

Thus, the guideline to avoid catching exceptions that you're unable to handle fully becomes a reality. In fact, any conditional check surrounding an empty throw statement can likely be flagged with a code smell and avoided. Consider adding an exception condition in favor of having to use an empty throw statement except to persist a volatile state before a process terminates.

That said, developers should limit conditional clauses to check the context only. This is important because if the conditional expression itself throws an exception, then that new exception is ignored and the condition is treated as false. For this reason, you should avoid throwing exceptions in the exception conditional expression. C requires that any object that code throws must derive from System.

Exception or even primitive types like int or string. Starting with C 2. Exception or not, will propagate into C assemblies as derived from System. The result is that System.

Prior to C 1. Exception block. In practice, the catch System. Exception block and general catch block—herein generically referred to as catch System. Following the general principle of only catch exceptions that you can handle, it would seem presumptuous to write code for which the programmer declares—this catch can handle any and all exceptions that may be thrown. First, the effort to catalog any and all exceptions especially in the body of a Main where the amount of executing code is the greatest and context likely the least seems monumental except for the simplest of programs.

Prior to C 4. This set is less of a concern starting in C 4. Exception or a general catch block will not in fact catch such exceptions. Technically you can decorate a method with the System. HandleProcessCorruptedStateExceptions so that even these exceptions are caught, but the likelihood that you can sufficiently address such exceptions is extremely challenging. See bit. One technicality to note on corrupted state exceptions is that they will only pass over catch System. Exception blocks when thrown by the runtime.

An explicit throw of a corrupted state exception such as a System. StackOverflowException or other System. SystemException will in fact be caught. However, throwing such would be extremely misleading and is really only supported for backward-compatibility reasons.

StackOverflowException, System. SystemException, System. OutOfMemoryException, System. COMException, System. In summary, avoid using a catch System. For example, if the catch block could successfully save any volatile data something that cannot necessarily be assumed as it, too, might be corrupt before shutting down the application or rethrowing the exception. FailFast method. Avoid System. Exception and general catch blocks except to gracefully log the exception before shutting down the application.

In this article I provided updated guidelines for exception handling—catching exceptions, updates caused by improvements in C and the. NET Framework that have occurred over the last several versions. In spite of the fact that there were some new guidelines, many are still just as firm as before. Go to itl. Therefore there should be no need to catch an exception only to rethrow it or throw a different exception. Though to this, I would argue that all these specific exceptions should derive from DatabaseException in the first place, so rethrowing is not necessary.

You'll find that removing unnecessary try catch clauses even the ones for purely logging purposes will actually make the job easier, not harder. Only the places in your program which handle the exception should be logging the exception, and, should all else fail, a program-wide exception handler for one final attempt at logging the exception before gracefully exiting the program.

The exception should have a full stack trace indicating the exact point in which the exception was thrown, so it often isn't necessary to provide "context" logging.

That said AOP may be a quick fix solution for you, though it usually entails a slight slowdown overall. I would encourage you to instead remove the unnecessary try catch clauses entirely where nothing of value is added.

Sign up to join this community. The best answers are voted up and rise to the top. Stack Overflow for Teams — Collaborate and share knowledge with a private group.

Create a free Team What is Teams? Learn more. Ask Question. Asked 3 years, 9 months ago. Active 1 year, 11 months ago. Viewed 21k times. Improve this question.

First is terrible practice. Second is perfectly fine way to improve your debuging experience. As pointed out by Amon. If your language has stack-traces, logging in each catch is pointless. But wrapping the exception and adding additional information is good practice. See Liath's answer. Any answer I gave would pretty much mirror his: catch exceptions as early as practicable and if all you can do at that stage is log some useful information, then do so and rethrow.

Viewing this as an antipattern is nonsensical in my view. Liath : added small code snippet. Show 7 more comments. Active Oldest Votes. The idea here is to enhance the ability to debug your application. Improve this answer. Berin Loritsch Berin Loritsch I liked " The problem isn't the local catch block, the problem is the log and rethrow " I think this makes perfect sense to ensure cleaner logging.

I think there must be some guideline to ensure this practice is followed judiciously rather than having every method doing so. I provided a guideline in my answer. Does this not answer your questions? There cannot be a general guideline that tells you where to handle an exception or when to rethrow it. Users of your code wouldn't be too amused if you logged things i.

Just my two cents : — andreee. Although you can establish an interface for logger and log only when it is set: logger?.

Log "error". There is also another point for Berin Loritsch: creating new instance of Exception will hide the original stack trace. Not that good for debugging. The pattern in both C and Java is to have a "parent" exception, so you can trace the exception stack trace all the way up the chain.

That's why in the example you see me passing the original exception into the wrapped exception with additional information. Point is that the problem in the original exception may or may not be the real thing you need to address. Main example would be in parsing where the input file is wrong.

Add a comment. TLDR Catching locally isn't an anti-pattern, it can often be part of a design and can help to add additional context to the error. Liath Liath 3, 1 1 gold badge 19 19 silver badges 33 33 bronze badges.