1

I understand that introducing ApplicationException to the exception hierarchy is retrospectively seen as a redundant move.

Likewise, I understand that there is no reason to derive application exceptions directly from SystemException, and that Exception should be generally used for this purpose. I can well imagine circumstances where derivation from ArgumentException or IOException could be a good idea, especially when implementing pre-existing interfaces designed/documented around those. However, deriving directly from SystemException in a application code would seem to me just as a very confusing equivalent to deriving from Exception, partly because I have no idea what SystemException is trying to represent. (Today. Not historically.)

MSDN says: "Serves as the base class for system exceptions namespace. ... This class is provided as a means to differentiate between system exceptions and application exceptions." What a circular definition. The class serves as a way of distinguishing between types derived from it and types not derived from it.

The whole historical distinction between exceptions originating in application code and in system code seems to me obsolete, especially in dependency injection scenarios where the catch clauses or documented conventions existed long before the throw points; so there's tons of well written application code that throws exceptions derived from SystemException.

Am I right in assuming that the raison d'être of SystemException if there ever was one vanished hand in hand with the demise of ApplicationException? Specifically, if this type suddenly disappeared from the inheritance hierararchy and its subclasses derived directly from Exception, would any solid coding techniques in common use be lost?

Community
  • 1
  • 1
Jirka Hanika
  • 13,301
  • 3
  • 46
  • 75
  • It was just defeated by common practice, nobody ever wrote his own ArgumentOutOfRange or InvalidOperation or NotSupported, etc, exception. Starting with the text editor :) – Hans Passant Oct 09 '15 at 10:48
  • @HansPassant - I'm sometimes inheriting from InvalidOperation, kind of thinking it classifies or documents my exception (type). But I'm more likely to throw InvalidOperation directly instead. I do understand that you are talking about much more influential software than ours :-) – Jirka Hanika Oct 09 '15 at 12:44

1 Answers1

1

The original intention was obviously to divide the exceptions into those that occur in the system and those that occur in the application. That distinction hasn't proved to be very useful, as those exceptions aren't generally handled differently. After all, all exceptions happen because of something that the application does, the system doesn't go around and just throw exceptions by itself.

When ApplicationException became more or less obsolete, so did SystemException, but there are a bunch of exceptions that inherit from the classes, so removing them would be a breaking change. There might be some applications out there which actually make use of them, so it's better to leave them where they are rather than risking that some applications stop working.

To classify exceptions based on where they are thrown isn't very useful for error handling, it could be more useful if you base it on how the exception could be handled. You might for example want exception base classes for errors that could be solved by repeating the process, and for errors that are not possible to recover from. That could actually be used in the error handling to handle the exceptions differently.

Guffa
  • 687,336
  • 108
  • 737
  • 1,005