Can anyone shed some light on the pros and cons of throwing custom exceptions (which inherit from System.Exception), or the proper way to use them? I'm already aware of the when/when not to throw exception, but I am looking for guidance on how to create my own custom exceptions.
These are all great posts. So far I agree most with Brian Rasmussen -- create custom exceptions when you want to handle different types of specific exceptions.
Perhaps an example will help. This is a contrived example, and may or may not be useful in everyday code. Suppose you have a class responsible for authenticating a user. This class, in addition to authenticating a user, has a lock-out mechanism to lock out a user after several failed attempts. In such a case, you might design as part of the class two custom exceptions: AuthenticationFailedException
and UserLockedOutException
. Your AuthenticateUser
method would then simply return without throwing if the user was successfully authenticated, throw AuthenticationFailedException
if the user failed authentication, or throw UserLockedOutException
if the user was locked out.
For example:
try
{
myAuthProvider.AuthenticateUser(username, password);
ShowAuthSuccessScreen();
}
catch(AuthenticationFailedException e)
{
LogError(e);
ShowAuthFailedScreen();
}
catch(UserLockedOutException e)
{
LogError(e);
ShowUserLockedOutScreen();
}
catch(Exception e)
{
LogError(e);
ShowGeneralErrorScreen();
}
Again, a contrived example. But hopefully it shows how and why you would want to create custom exceptions. In this case, the user of the AuthProvider
class is handling each custom exception in a different way. If the AuthenticateUser
method had simply thrown Exception
, there would be no way to differentiate between the different reasons why the exception was thrown.
There's actually a great series of MSDN articles on this topic:
These are all great posts. So far I agree most with Brian Rasmussen -- create custom exceptions when you want to handle different types of specific exceptions.
Perhaps an example will help. This is a contrived example, and may or may not be useful in everyday code. Suppose you have a class responsible for authenticating a user. This class, in addition to authenticating a user, has a lock-out mechanism to lock out a user after several failed attempts. In such a case, you might design as part of the class two custom exceptions: AuthenticationFailedException
and UserLockedOutException
. Your AuthenticateUser
method would then simply return without throwing if the user was successfully authenticated, throw AuthenticationFailedException
if the user failed authentication, or throw UserLockedOutException
if the user was locked out.
For example:
try
{
myAuthProvider.AuthenticateUser(username, password);
ShowAuthSuccessScreen();
}
catch(AuthenticationFailedException e)
{
LogError(e);
ShowAuthFailedScreen();
}
catch(UserLockedOutException e)
{
LogError(e);
ShowUserLockedOutScreen();
}
catch(Exception e)
{
LogError(e);
ShowGeneralErrorScreen();
}
Again, a contrived example. But hopefully it shows how and why you would want to create custom exceptions. In this case, the user of the AuthProvider
class is handling each custom exception in a different way. If the AuthenticateUser
method had simply thrown Exception
, there would be no way to differentiate between the different reasons why the exception was thrown.
Use your own exceptions to flag errors which are specific to your application/domain. The advantage is that your catch blocks can filter the correct exceptions and act upon that. Use specific standard exceptions for everything else.
Custom exceptions allow you to provide clear, meaningful exceptions, which in turn can make your library more usable, provided you use the existing exceptions whenever appropriate.
Create a custom exception any time you need to raise an exception that doesn't fit directly in the framework's exception model.
I recently wrote an entire blog entry on this particular subject:
- http://blogs.msdn.com/jaredpar/archive/2008/10/20/custom-exceptions-when-should-you-create-them.aspx
The basic summary though is ...
You should only create a new exception if you expect developers to take corrective action for the problem or to log for post mortem debugging.
© 2022 - 2024 — McMap. All rights reserved.