The answer is of course "it depends," but given your use case, I would say no. Here's why:
When I get in this "mode," this sort of paralysis, one of the symptoms can be an obsession with exception handling and generics and meta-programming. Sometimes all three together. It is far more likely to be an issue when I am working on something new, relatively unknown, or with shoddy specifications and goals. Rather than bogging myself down in the implementation details, I think, why try to create something that can accommodate most of the scenarios I reasonably anticipate? Then, when I get around the getting the details, the foundation will be laid and I will write a bunch of stubby little methods, and so on. Maybe somebody else will work on the UI code, I'll just provide them these nice services and these contracts...
Unfortunately, that has yet to happen to me. What tends to happen is that I start down this path working on "infrastructure" - things like:
- Writing my own IoC container interfaces or otherwise screwing around with
- Determining how I am going to handle type mapping in the application
- Writing control flow logic for abstract base classes that resemble
Interceptors and wrapping calls to abstract members with exception handling
- Creating abstract base classes for
- Trying to describe a hierarchical object model for something whose very nature denies such a meta- approach (like
When you get hung up on whether an exception's description is precise enough for your tastes, you are really denying some other critical feature from being implemented. The nature of the exception is also telling - it is not an event-driven exception, it occurs evidently far from any input methodology (like a UI or a pipe or something) and is probably deterministic in nature - as in, you can't predict what a user will input, but you can predict which assembly you choose to load or whatnot.
By the way, if the description bothers you so much, can't you write an extension method to override it in the appropriate scope?
So this is really just me kind of projecting my own over-abstraction and analysis paralysis onto you but I think it may be appropriate. I would say that to stay on the safe side, only subclass an
- You have actually experienced a runtime exception that you are seeking to handle in general
- The runtime exception is not something that you could reasonably rule out at design time
- The exception is not already well-covered by the huge existing number of
- You actually have an idea in mind of how you want to handle the exception OR if not, only because it is so complicated that you need to think about it and get back to it
- Your idea goes beyond changing its metadata, its scope, its inner exception, etc, and deals more with the underlying object or event producing the exception and/or the means of actually dealing with it
- You have already written or are not responsible for the majority of the input-facing side of things like the UI