2

I have decided to use Exceptions in my code to pass error handling around. I found myself duplicating code each time I wanted to create a new exception. These classes were nothing special and only contained a messaged. But I have come to rely on type safety when handing them. Is there a way to provide a new exception class type without having to re-implement the constructors?

[Serializable]
class MyNewException : MyBaseException
{
    public MyNewException (String tMsg)
        : base(tMsg)
    {
    }

    public MyNewException (String tMsg, Exception tInnerEx)
        : base(tMsg, tInnerEx)
    {
    }
}

The code above is duplicated many times over for each different type of exception I want to define.

John Saunders
  • 160,644
  • 26
  • 247
  • 397
MarkP
  • 4,168
  • 10
  • 43
  • 84
  • 2
    You also need a serialization constructor. – SLaks Nov 28 '11 at 01:40
  • See [Design Guidelines for Exceptions](http://msdn.microsoft.com/en-us/library/ms229014.aspx). It will tell you why you should reduce duplication by using fewer custom exceptions. – John Saunders Nov 28 '11 at 02:26
  • If a method will throw an exception for some particular condition a caller might want to handle, there should be no way for the caller to get an exception of that type except when the condition in question occurs. Ensuring this will require either that the method catches any exception of that type that occurs within it and wraps the caught exception in some other type, or else that the method throws some type of exception which none of its nested methods are going to throw. The first behavior may be counter-intuitive; the latter will require more custom exceptions. – supercat Nov 28 '11 at 18:07
  • It's really too bad there's no standard way of distinguishing 'clean failure' exceptions (where the system state after an attempted operation is the same as before, and where--from the point of view of the class throwing the exception--the system state is just fine but the request may have been invalid) from 'CPU on fire' exceptions (the system state is severely corrupted; the system should perhaps release resources but not attempt to continue normal operation). It would probably be hard to add such a thing now, though. – supercat Nov 28 '11 at 18:18

1 Answers1

1

Unfortunately, no, the constructors have to be provided since they are not inherited.

In addition, unless you are catching these specific exceptions and performing explicit processing when they occur, I would recommend having a generic exception that contains the additional information that you might need. However, this may not apply in your case.

competent_tech
  • 44,465
  • 11
  • 90
  • 113
  • 1
    I do have a generic exception for when I don't care about context. I do have many context specific exceptions that inherit from my base exception. – MarkP Nov 28 '11 at 02:59