What is the reason why .NET does not have a conceptual (Fatal-) type of error exception?
Preliminary note:
This question is not intended for bash on .NET and is not intended to lead a discussion of war if there is such a thing as "Fatal Exception" - Java developers clearly thought there was , .NET developers either thought differently, didn't know otherwise, or maybe another (technical) reason for the exception hierarchy to be what it is.
What I'm most interested in is if there is a design document or expression by any of the MS developers why the .NET hierarchy is as it is today. Wild guesses and speculation will make bad answers. Explanatory arguments / examples why not "Such a thing as (categorizable) " Fatal Exception "can certainly give correct answers, although I disagree with them. But unlike the comments, I promise not to argue with any cohesive answer ; -) Another category of answers might suggest that Java category categorization Error
is a bad idea / doesn't work in practice in Java, thereby implicitly demonstrating why .NET doesn't need it. :-)
While working on becoming a more experienced C # programmer, I noticed something that I find quite strange (*) in . :
Base class for all cast types Exception
( well, anyway, anyway ).
In particular, many exceptions directly follow from Exception
and further categorization into SystemException
→ etc. seems pretty pointless a little arbitrary.
As an example, especially strange to me, it seems that SEHException
there is -a ExternalExpection
is-a SystemException
when it seems to be more like a bug and burn.
Without being too proficient in Java, I find that the Java distinction is wrt. Error
type vs "normal" Exception
to make a lot of sense. The details can certainly be argued, but .NET
/ C # not even trying this approach seems odd.
Eric Lippert of the C # fame has a nice thing about exception categorization that I mostly agree with, and which makes me wonder even more why .NET isn't even trying to provide a bucket for "Fatal Exceptions".
In the Fatal Exception section, I basically refer to the same concept that Mr. Lippert describes:
Fatal exceptions are not your fault, you cannot prevent them, and you cannot intelligently clear them ....
Note. Most importantly, they are most likely not the error of the operation you are calling that raised the exception either.
... They almost always happen because this process is deeply affected and poverty is gathering. Out of memory, thread aborted, etc. There is absolutely no point in catching them because nothing your shadow user code can do to fix the problem. Just let your "final" blocks work and hope for the best. (Or, if you're really worried, don't be quick and don't finally let the blocks work; for now, they might just make things worse. But that's a topic for another day.)
Note that for some set of fatal exceptions, technically just like any other exception is quite normal. ... You have to catch it very well at the right time - it's just that for 99% of the code, it's not good enough to handle them at all.
Take Mr Lippers' examples: let's say I call a function to open a file that can raise various exceptions. If I catch any of them, all I want to do is report that opening the file failed with reason X and proceeded accordingly. However, if opening a file throws, say, a ThreadAbortedException, it makes no sense to report anything, since the file open operation does not work, but some code interrupted the current thread and the handler, which at the same moment as the hypothetical FileNotFoundException make sense in the vast majority of cases.
It seems like commenters think that only the catch site can really judge whether something is "fatal" and no prior categorization is appropriate, however I would strongly suspect that there is a good list of exceptions that 99% of user code never wants to catch :
Take StackOverflowException
(and I'm sure there is more), which is "just" a regular SystemException.
In the .NET Framework 1.0 and 1.1, you can catch a StackOverflowException (for example to recover from unlimited recursion). Starting with the .NET Framework 2.0, you cannot StackOverflowException with a try / catch block and the associated process exits by default.
Please note that I don't think a fatal exception should terminate the application immediately (on the contrary). All I'm asking is why the .NET framework doesn't try to represent "fatality" in the exception hierarchy, when developers clearly think some exception is more fatal than others.
(*) "considered rather odd" actually means that I personally find the .NET exception hierarchy completely unsuccessful at this very point in the time continuum .
source to share
First of all, let me say that this is not a very good question for StackOverflow. This is not a specific technical question about real code, but rather looking for either a design document - an off-site resource or an excuse for why a particular class hierarchy was designed the way it was. Nothing works well for SO.
However, I can make a few points here.
I think it's a reasonable assumption that all members are sorry for the existence of SystemException
and ApplicationException
. At the time, it seemed like a good idea to divide exceptions into two broad categories: exceptions thrown by the "system" itself, and exceptions thrown by users of the system. But in practice this is not useful because what you do with exceptions is their trick, and under what circumstances do you want to catch either (1) all custom exceptions or (2) all system exceptions? No circumstance comes to mind.
This illustrates not so much the failure of the design in a particular case - although the design is certainly small, but rather the fact that in OOP with one inheritance, you only get one shot at the "inheritance point" as it is often called in Microsoft, and a bad decision can take a long time hold on to you.
It is now very easy to say that in retrospect we could have used some other pivot. You note that in my article I am classifying exceptions according to how they should be caught - fatal exceptions are not caught because you have no good catching them, pointy exceptions are not caught because they actually debug helpers, annoying exceptions should be caught due to poor API design, and exogenous exceptions must be caught because they show that the world is different from what you hoped. It looks like there is an opportunity here to create a better quality pivot where the type of exception indicates whether it is fatal or not and indicates whether it should be caught or not. This, of course, is not the only possible pivot, but it seems plausible.It was possible to design a static analyzer (either in the compiler or in a third party tool) that checks for the correctness of the correct exception.
This seems particularly plausible because of course there are some exceptions in .NET that are effectively super puer fatal. You can catch a stack overflow or thread interruption, but the system is aggressive about re-throwing. It would be nice if they somehow got into the metadata.
As a language designer, although I would take this retrospection further, to say that the main problem here is that the exception mechanism itself is overloaded, if not overused.
For example, why do we need fatal exceptions to be exceptions? If it is true that some exceptions are fatal, and in fact it happens in some rare but important scenarios, you need the code to run, even if the program crashes due to a fatal exception, then this scenario can rise to a level that which you want the syntax of the language to remember these semantics. Tell the block try-fatality
where the cleanup code only works in the extremely unlikely event of a fatal error. Maybe it's a good idea, maybe not, but the point is that the idea of putting a function in a language to solve a problem rather than imposing more and more semantics on a mechanism that doesn't seem to be ideal for all uses that it is placed in.
For example, why are there "crazy" exceptions at all? Existence of head-thrown exceptions, such as "this reference cannot be null, bogus" or "you tried to write to the file after it was closed, you are bogus" are actually only exceptions, since they are flaws, in the first case - the type system, and the second is the API design. Ideally, there would be no chatter exceptions, because it would simply be impossible to imagine a bad program in that language in the first place. Mechanisms such as code contracts can be built into the language to help ensure that the "exception" situation is caught at compile time. Again, maybe this is a good idea or maybe not, but the point is, there is an opportunity to solve this problem at the level of language design,instead of having an exception carry that burden, then asks how to create a hierarchy of types that clearly represents a preconceived exception.
source to share