Pros and cons of implementing a universal custom exception

Question

What are the advantages and disadvantages of implementing a custom exception as follows:
Create an enumeration that represents error messages in its descriptions:

public class Enums { public enum Errors { [Description("This is a test exception")] TestError, ... } } 

Create your own exception class:

 public class CustomException : ApplicationException { protected Enums.Errors _customError; public CustomException(Enums.Errors customError) { this._customError = customError; } public override string Message { get { return this._customError!= Enums.Errors.Base ? this.customError.GetDescription() : base.Message; } } } 

The GetDescription method is an enum extension method that gets a description of an enumeration using reflection. This way I can throw an exception, for example:

 throw new customException(enums.Errors.TestError); 

And show it to the user in the catch block, for example:

 Console.WriteLn(ex.Message); 

I have seen this approach recommended by MVP. What are the benefits of this approach for the following:

• Using a generic exception: throw new Exception ("Error message") ;.
• Use custom exceptions: Define custom exceptions for any situation. for example ( WebServiceException class, AuthenticationException class, etc.)

Here is a link to the MVP recommendation.

Thanks.

Answer 1

Personally, I do not think this is a good idea.

You should always throw as specific exceptions as possible. The same goes for fishing.

It's easy to decide if we want to catch a WebServiceException or AuthenticationException , but with your Enum example, we need to parse the string to decide whether we want to catch it or not. What happens if this message changes?

I don’t think he has any advantages. For each type of error, you must create a new Enum member. Why not create a new class instead?

Answer 2

The main advantage of custom exceptions is language support for differentiating between different types of exceptions. for instance

 try { SomeFunc() } catch( CustomException EX) { //This is my error that I know how to fix FixThis() DoSomeAwesomeStuff() } catch( Exception exa) { //Somthing else is wrong WeepLikeBaby(); } 

If I use the message Property

 try { SomeFunc() } catch( Exception exa) { if(exa.Message == "ErrType 1") { DoStuff; } if(exa.Message == "ErrType 2") { Die(); } } 

Using the Base enumeration example can save this possibility. However, you give yourself one place to define your messages, but this solution is resolved in various ways. The listing example will make creating localized messages pretty easy, as it will give you a way to define your message strings independently.

Another advantage is that you can add Cusotm data that makes sense in your application. Say, for example, you have an information system for customers, and the customer ID will almost always be important. If you use the message property only, each handler will need to know how to parse this information, if necessary.

 public class MyCustomeEx : Exception { int CustID { get; set; } } public void Fail() { //Awww Customer error throw new MyCustomeEx () {CustID = 123} } 

Answer 3

Option 1 I would not recommend. You should not throw a System.Exception at all. You should always throw the most specific exception available for your situation in order to have reasonably structured exception handling in your code.

The main drawback that I see in the method you proposed ( Errors enum ) is that you cannot decide whether you want to process or not exclude without first catching it. With custom exceptions, you can make this decision in advance.

Answer 4

See my (accepted) answer for the following similar question: Custom exception and inline exception with a very descriptive message . It should be useful in providing arguments against forbidden user exceptions.

Answer 5

The link to the MVP recommendation was provided in the comments.

Looking at the code and the question, I think the reason is to limit the possible messages to an exception. And maybe help with the localization of exception texts, but then in this example, you have more work to do. In any case, such a method should not be used to create “exception subtypes,” which are handled differently.