Menu
So, we are using the Enterprise Library 4.1 Exception Handling Application Block to deal with logging/handling our exceptions in a multiple-project application. We have a few custom exceptions and are throwing some exceptions whose classes are defined in the .NET framework's standard class libraries (e.g. ArgumentException, InvalidOperationException, ArgumentNullException, etc.).
Today, our team lead decided that he didn't want us to use the latter, since the .NET framework would throw those types of exceptions, and in order to facilitate filtering with the application block's policies, we should use only custom exceptions, going so far as to practically duplicate .NET standard class library exceptions with custom versions, as in CustomArgumentException, CustomInvalidOperationException, etc.
My question is, what is wrong with this approach? I couldn't put my finger on it at the time, but it smelled wrong to me and I haven't been able to shake my uneasy feelings about it. Am I worried about something that really isn't that big of a deal? I guess it just feels like the tail wagging the dog a bit here...
383
2. Don't use exceptions to control logic. If you are using exceptions to control the flow of logic, you are probably doing something wrong. If it is acceptable for a method to return a false or null value, then this doesn't require an exception.
The big advantage is that it allows you to throw and exceptions that mean what you want them to mean. If you reuse an existing exception, any piece of your code that catches the exception has to deal with possibility that the actual exception wasn't thrown by your code, but by some other library party code.
You can create your own exceptions in Java and they are known as user defined exceptions or custom exceptions. All exceptions must be a child of Throwable. If you want to write a checked exception that is automatically enforced by the Handle or Declare Rule, you need to extend the Exception class.
You should only implement a custom exception if it provides a benefit compared to Java's standard exceptions. The class name of your exception should end with Exception. If an API method specifies an exception, the exception class becomes part of the API, and you need to document it.
Ick. What I don't like about it is:
ArgumentException.I would suggest you get your team lead to read item 60 of Effective Java 2nd edition. Yes, it's about Java rather than C# - but the principles remain the same.
132
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
