Exception Handling using throw Vs throw ex Vs throw new – Best practices
In this article, we will try to understand Exception Handling using Throw Vs Throw ex Vs Throw new Exception(“<Message”>).
Today in this article, we will cover below aspects of exception handling,
In our previous article, we already talked about below aspects and techniques of exception handling which are important while considering proper design around exception handling,
- Exception handling
Getting Started
Here is an example of a project structure ultimately we will be dealing with. This early structure will give you a clear idea of how the exception hierarchy will be maintained using a stack trace by understanding a few basics of throw keywords.
As we know stack trace is a list of call hierarchies that starts with the method and line of code that throws the exception and it ends with the method and line of code that catches the exception.
In the above example, we will perform some exception activities in the Data Access layer. Here I am simply trying for the DevideByZero exception.
We have used the short name below,
BAL – Business access layer
DAL – DataAccess Layer
For all the below samples, we are making sure only the highest layer of your application swallowing it. i.e API/Service layer will swallow the exception.
Using throw ex – Exception handing
Let’s try using throw ex in each layer like BAL and DAL.
Once exception activity happens in the DAL layer. So if we use Throw ex, we found now that it doesn’t maintain the stack trace details.
However, the issue happened in the 3rd layer i.e DataAccess Layer but since we used throw ex, we lost the details of the source of that error. As shown below we have traces from the business layer only.
Disadvantages:
- Might miss the upstream layer completely.
- The source or origin of the issue will be unknown. Ex. Above line number 40 in the Business layer is not the actual code where the exception occurred.
- It will be difficult to find the root cause and troubleshoot the issue.
- If you need to retain stack trace, you may need to write extra logic/code.
Using ‘throw’ in Exception Handling
Let’s try using only the ‘throw‘ keyword in each layer like BAL and DAL.
Once exception activity happens in the DAL layer.
So if we use throw, we found now that it does maintain the stack trace details. It also clearly shows the source component and line at which the exception or issue has occurred.
Advantages:
- Keep stack trace details intact.
- You don’t need to write custom logic to keep track of all errors.
- Keep details of source component where exception was thrown.
- Provide details of exceptions with a precise line of code where the issue occurred.
- Easy to troubleshoot the issue.
Using ‘throw new CustomException()’
One may find a need to raise a custom exception or business exception in the application. Using ‘throw new’ with your custom exception class will help you raise such exceptions.
So ideally there is no difference between throw ex vs throw new Exception() as both reset your stack trace details. But later got the advantage of allowing to take care of business exception handling.
Let’s try using only the ‘throw new CustomException()’ keyword in the DAL layer. In other layers, throw statement is being used.
Once exception activity happens in the DAL layer.
So if we use throw new Exception(), we need to understand that it does maintain the stack trace details but only when it is used in combination with throw keyword across other downstream layers. Other wise it behave like ‘throw ex‘ loosing your stack trace details.
It also clearly shows the source component and line at which the exception or issue has occurred.
Advantage:
- Best for throwing Business exceptions in the layers with the advantage of maintaining stack trace.
- Keep stack trace details intact if used in combination with the throw keyword in other downstream layers.
- Keep details of source component where exception was thrown.
- Provide details of exceptions with a precise line of code where the issue has occurred.
- Easy to troubleshoot the issue by keeping business and technical exception details.
Disadvantage:
- You will lose stack trace details if not used with throw or custom logic in the downstream layer.
- One needs to be extra careful while using this. One could limit its usage for business or custom exception purposes as needed.
References:
Do you have any comments or ideas or any better suggestions to share?
Please sound off your comments below.
Happy Coding !!
Summary
Today in this article we understood the difference between throw vs throw ex vs throw new keywords. In general, to keep the original stack trace details with the exception, use the throw without specifying the exception. Your exception handling mostly should use ‘throw’ (for normal regular exception handling) and ‘throw new’ (for business exception handling) and follow the best practices as mentioned above in the article. One can avoid using ‘throw ex’ statements in the code.
Please bookmark this page and share it with your friends. Please Subscribe to the blog to receive notifications on freshly published(2024) best practices and guidelines for software design and development.