Is it better to catch exceptions and throw them or just let them throw them time?
Let's assume there is a setting like this:
public class MyClass
{
public void DoSomething(string Data)
{
//if (String.IsNullOrWhiteSpace(Data))
//throw new NullReferenceException();
//Do something with Data and let it throw??
}
}
public class EntryPointClass
{
public void DoIt(string Data)
{
var logicClass = new MyClass();
try
{
logicClass.DoSomething(Data);
}
catch(Exception ex)
{
}
}
}
In DoSomething, I can detect the problem and throw an exception. When testing the EntryPointClass, I can check the expected result, or check that something happened in the catch.
Why is it better to make an exception rather than just wait for it to happen? We caught him anyway!
source to share
You do both:
public void DoSomething(string Data)
{
if (String.IsNullOrWhiteSpace(Data))
//throw new NullReferenceException();
throw new ArgumentException("Data");
//Do something with Data and let it throw??
}
The goal is to quit early and provide specific information.
The direct reason for this is that the contract has been DoSomething()
violated. Sign this, don't wait for `DoSomething () to continue and break other contracts.
Crash fast, crash early.
source to share
Retrieve your own exceptions so you don't see from the outside the actual source of the exception and therefore have information about your implementation.
You can exclude an argument argument with a custom message or custom exception to provide more details on why the argument is invalid.
source to share
The point of use for exception handling is handling exceptions that may be out of your control. If you plan to wrap your code in a try-catch block except for a NullReferenceException, then you must have something in place to handle this type of exception and perform any necessary operations related to this error.
If you say that in situations where you know that you might have an error that would throw an exception, it is better to check this situation - and not throw an error at all, but handle it gracefully. Otherwise, you just code on the exception, which is the anti-pattern.
Remember that exceptions are exactly that exception, exceptions for your rules, not catch-all for anything that might go wrong as your code is executed.
source to share
Consider the exclusion of the person jumping out of a burning house and crying for help: you don't want them to scare the population, but you want them to notify the right people to do something about the fire. With this in mind:
1) If you have something wrong in DoSomething And you know how to fix it - you don't need an exception: just fix it inside DoSomething.
2) If DoSomething is having problems handling the problem (wrong attribute, unavailable resources, etc.) - use the exception to ESCALIZE the problem and handle it at a level where such handling is possible.
3) If DoSomething is screwed in such a way that you cannot influence in any way (for example, file system crashes and IO exceptions all over the world) - just catch the exception, write it down and turn it off gracefully - at least it won't look like an implosion.
source to share
One set of circumstances where you shouldn't try to spot an error condition ahead of time, rather than just skipping code, is where there is a dependency on an external resource outside of your control of the code. For example. everything related to the network, file system, etc.
The problem with either of these is that the verification code can succeed and then the actual operation can complete. Everything you did by adding validation code increased the amount of code you wrote — you still have to write code to deal with real-world crashes.
source to share
Eric Lippert has an excellent article on Exception.
Please follow the link. This is a very good resource on how you should handle exceptions.
As a general rule, try to avoid exceptions rather than trying to handle the exception. And don't catch all exceptions. I can see Catch(Exception ex)
in your code. Catch an exception that you can handle. There is nothing you can do when you receive OutofMemoryException
,ThreadAbortException
I agree with Henk Holterman
.
source to share