Home/ Questions/Q 146131
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T08:32:49+00:00

So, we are using the Enterprise Library 4.1 Exception Handling Application Block to deal

  • 0

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…

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Ick. What I don’t like about it is:

    • It duplicates existing types
    • It violates the principle of least surprise
    • It means that if you want to find everywhere you’ve used the wrong argument value (say) you have to look for two type hierarchies of exception instead of just looking for 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.

    • 0