I’m glad to have received good exposure to both C# and Java. I feel like I’ve learned a lot by seeing how the two solved similar problems in different ways. It’s even more enlightening when supplemented by books like Effective Java or the annotations from .NET Standard Library Annotated Reference.
In the SLAR, the annotation says that SystemException and ApplicationException shouldn’t be used, that they unnecessarily add to the inheritance depth of exceptions for little value, and that custom Exceptions should inherit directly form System.Exception. I also saw in an Artima interview with Anders Hejlsberg the reasoning why C# doesn’t have checked exceptions.
On and off, I thought about that in comparison to Java’s stance on exceptions. I eventually realized that the division between C#’s SystemException and ApplicationException is the same as the division between Java’s RuntimeException and other Exceptions.
Whether exceptions are generally checked or unchecked is a separate decision. I think the designers of both languages decided that there was value in separating errors into those that are problem domain errors (i.e. errors that can be described in the language of the ultimate problem being solved) and errors that are lower level programmatic problems (e.g. array bounds, null pointers, framework failures).
The advice that SystemException and ApplicationException should be ignored is consistent with C#’s other decision about exceptions: that they should all be unchecked. Checked exceptions force a rigor and precision around the error scenarios (major and minor) that many developers, perhaps pressed for time, find unpleasant. Separating exception types into System and Application errors would require a similar increase in rigor, and this time without the aid of a compiler.
