If throwing System.Exception is considered so bad, why wasn't Exception made abstract in the first place?

That way, it would not be possible to call:

throw new Exception("Error occurred.");

This would enforce using derived exceptions to provide more details about the error that occurred.

For example, when I want to provide a custom exception hierarchy for a library, I usually declare an abstract base class for my exceptions:

public abstract class CustomExceptionBase : Exception
    /* some stuff here */

And then some derived exception with a more specific purpose:

public class DerivedCustomException : CustomExceptionBase
    /* some more specific stuff here */

Then when calling any library method, one could have this generic try/catch block to directly catch any error coming from the library:

    /* library calls here */
catch (CustomExceptionBase ex)
    /* exception handling */

Is this a good practice?

Would it be good if Exception was made abstract?

EDIT : My point here is that even if an exception class is marked abstract, you can still catch it in a catch-all block. Making it abstract is only a way to forbid programmers to throw a "super-wide" exception. Usually, when you voluntarily throw an exception, you should know what type it is and why it happened. Thus enforcing to throw a more specific exception type.

  • 4
    +1 "The best way to prevent incorrect use is to make such use impossible." - Scott Meyers Nov 14, 2011 at 16:04
  • 5
    "Would it be good if Exception was made abstract?" - Abslutely not, because all of the existing .NET code which uses new Exception("...") would break. However, "Should the .NET team have made Exception abstract to begin with?" - probably, yes, but it's >10 years too late now :)
    – MattDavey
    Nov 14, 2011 at 17:00

2 Answers 2


I don't know the actual reasons why it was done this way, and to a certrain degree I agree that preventing infintely wide exceptions from being thrown would be a good thing.

BUT... when coding small demo apps or proof-of-concepts, I don't want to start designing 10 different exception sub-classes, or spending time trying to decide which is the "best" exception class for the situation. I'd rather just throw Exception and pass a string that explains the details. When it's throw-away code, I don't care about these things and if I was forced to care about such things, I'd either create my own GenericException class and throw that everywhere, or move to a different tool/language. For some projects, I agree that properly creating relevant Exception subclasses is important, but not all projects require that.

  • I completely agree with you, but the question was implicitly thinking about non-trivial projects. Nov 14, 2011 at 19:34
  • It's also the kind of issue that humans easily work around. Once Exception is no longer available as a quick option (such as in demo's), then people will start using some other exception type as their goto "some exception" type.
    – Flater
    Jul 20, 2022 at 8:57

Possibility A: It's logically correct.

You are correct that Microsoft, along with many others do not suggest throwing a new Exception() directly for a plethora of reasons.

That being said, we can consider the academic ideal that the purpose of a the Exception class hierarchy is to define a narrowing effect so that only the most specific exceptions can be caught. (i.e. ArgumentNullException is narrower than ArgumentException).

The Exception class is no exception (pun not intended). It is intended to be the broadest possible exception, a "super exception" that almost cannot be caught because its scope is infinitely wide. 'Exception' it is not abstract in the sense that Exception cannot exist as an entity on its own. It can (though admittedly no good cases are defined yet - see Possibility B), and therefore should be publicly constructible.

The 'abstract' keyword (in a purely academic sense) is only applicable when the base class makes no sense on its own - i.e. FourLeggedAnimal.

All of this in mind, there would be no technical reason to make the class abstract, other than to be a source of aggravation to developers.

Possibility B: Design Lock-in / They didn't know

If MS made this class abstract, they may have been in trouble if they changed their mind down the road, as this class is very essential to the fundamentals of the language. They already goofed with ApplicationException, so it's foreseeable that they anticipated a change in recommendation down the road, too. (see Link)

There may be other reasons (I am thinking maybe this has to do with Reflection, or some other technical reason), so I am making this post a CW.

  • "Just because it is "super-wide", it is not abstract." ... But that's the OP's argument isn't it. Shouldn't it be abstract in the sense that some indication of the type of exception always needs to be passed. Nov 14, 2011 at 15:59
  • Good point, I will update my answer accordingly - the nature of this question is a little confusing because 'abstract' is both a language keyword as well as the name of the concept being discussed. Nov 14, 2011 at 16:45
  • @KevinMcCormick : The term 'abstract' here is used as the language keyword. Please tell me how I can change my question so it is clearer for future readers ? Nov 14, 2011 at 16:59
  • I think it's a great question. Any OO conversion regarding the abstract keyword hits this wall. Not sure of any way to get around it other than denoting the abstract keyword with the backticks. Nov 14, 2011 at 17:01
  • 2
    How is "disabstracting" a class a breaking change? Nov 14, 2011 at 17:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.