When to use a user defined Exception and some good examples/best Practices?

Question

I would assume that most User-defined Exceptions are for Business Logic level exceptions, but what are some good reasons to use a User-Defined Exception and what are some good examples?

Is a user-defined exception's only advantage that you can define a consistent Error Message?

What logic can be written inside exceptions to make them truly more useful?

After all, can't you just do this: throw new Exception("Some Error Message");

Answer 1

Having user-defined exceptions is useful because it allows you to handle different kinds of errors in specific ways. Why does .NET define so many different types of exceptions if they could just throw all exceptions as System.Exception with a different text message? The reason that there are different types of exceptions in .NET is that you can catch individual types of errors and handle them differently. That's the same reason you would define your own user exceptions - so that you can provide a different response based on the type of exception that occurred.

You can also create user-defined exceptions that include additional data. For example, you could define a severity level based on an enum, an integer error code or anything else that might be useful to the calling program to identify what went wrong. As for logic to include in exceptions, I generally just try to report what went wrong and leave the logic (what to do about the error) to the calling program. In some cases, I have the exception code automatically write the error to a log file if it has exceeded a certain severity level (e.g. warnings are thrown but only critical errors are written to the log file).

Answer 2

You should create very few user-defined exceptions. They should only be used if someone is going to catch the exception and do something specific with it. If throwing your exception instead of InvalidOperationException is not going to make the code behave differently, then throw InvalidOperationException.

Answer 3

There are quite a lot of Exceptions already in the .NET framework, which you should use if you can find one that could be used for your exceptional circumstance.

For example, in my configuration classes (which are normally wrappers around the ConfigurationManager) I throw ConfigurationErrorsException when ever a value can't be parsed correctly.

When parsing custom values from text or something else that requires a specfic format and the parsing fails, I throw a FormatException

However if my BankAccount object doesn't have enough money in it for me to withdraw £10 then I'll write and throw InsufficentFundsException because then that way I can handle that specific error case, if it ever occurs.

Hope this (somewhat) helps.

Answer 4

No, they are not only for messages. You can look for User defined ones in the exception list of a catch block.

catch(UserDefinedException){}
catch(Exception){}

You can use User Defined Exceptions anytime you want to look for something specific that occurs. Maybe a Client ID is out of a specified range and you want to look for that specifically. Instead of having to parse the error message (which can be a pain, and is prone to errors, like if the message changes later down the road), you have an exception you use and you know that somewhere else in the code is specifically telling you "Hey this happened. You need to be aware of it."

Answer 5

User defined exceptions can be used within a component to allow consumers of the component the ability to catch them with a greater level of granularity then the catch (Exception) block. This will provide the component consumer with the ability to perform different tasks, based on which exception has been thrown. User defined exceptions should only really be created when there is a real expectation that consumers will use them to differentiate in this way.

Answer 6

You can also add properties to store additional meta-data with a user-defined exception, such as an error code (for example when calling an unmanaged API). This is more user-friendly than simply putting stuff into the Data property of the Exception object.