checked and unchecked exception in .NET

a strange idea comes to me when I'm reading APUE(Advanced Programming in UNIX Environment).

It seems that in UNIX's error handling, there are two types of errors (FATAL & INFATAL). I feel like it's something related to checked and unchecked Exceptions in JAVA.

So, to sum up, in a program, you have two kinds of errors, one of them is critical and will make system crash and you can do nothing about it. Another one is more like a signal that you can catch and do something to fix it.

I heard that in C# there is no checked and unchecked exception, so does C# not have a concept of critical and uncritical errors? Just got very curious becau开发者_StackOverflow中文版se i think this concept is very fundamental.

Update: What is the exception design in other languages? Can anyone talk about this?

In Java, checked and unchecked exceptions don't exactly map to a fatal or non-fatal error. A checked exception explicitly is stating that the exception may be thrown and someone must catch it (to try to handle it or throw it up the stack), but there is no guarantee that the error may not be fatal (i.e. a syntax error in an SQL query will throw an SQLException and will likely be fatal, but it is a checked exception). An unchecked exception just means that someone doesn't need to catch it, but you still can if you want. It would typically indicate a programming error. Java Errors typically indicate things that are unrecoverable problems (such as an OutOfMemoryError).

The C# design of unchecked exceptions just means you don't need to catch the exceptions, and if uncaught will crash the application. Checked vs unchecked exceptions has been a long standing debate in the development community and there are pros and cons to both. Typically though, you can't do something about an exception and it frequently just ends up getting logged rather than handled, so C# made exceptions unchecked. When you can handle them (for example, if you want to retry an IO operation), you can still catch them and retry.

I have, in previous systems that I no longer work on, created 2-level (fatal and non-fatal) exception systems in .NET -- mainly just by inheriting from the Exception class into two further base classes (FatalException and NonFatalException) and then deriving further, more specific Exception classes from these two. The fact that I no longer work this way demonstrates that I no longer feel this is necessary -- it just added to the ceremony of the system without adding much value.

IMHO a c# compiler built in exception class attribute like [CriticalException] vs. [NonCriticalException] would be nice. If you decorate your exception class with this attribute or (MS in the .NET runtime), the compiler would give you a warning, if no catch-block can be found somewhere in the call graph, assuming that in the call graph this specific exception is thrown.

Yes, there are such critical exceptions. For example, since version 2.0 of the framework, a StackOverflowException cannot be caught in a try-catch block

In C# there are special exceptions that you can't really recover from (I think all of them are related to memory issues) - but they are all system exceptions and you can't create a new one of these.

There is no mechanism to force the programmer to catch (or put declare throws) like in Java - all exceptions would be classified as unchecked. Obviously you can still catch them and recover, but the compiler is not going to help you with this one.

In C#, you also have the ability to catch unhandled exceptions at an application level. These will be caught as errors (page error, application error), not exceptions, but you have access to the last exception so that you can at least log them. At this point, you no longer have the option of fix-up and retry, but logging is crucial because your app is already going down.

No idea what the equivalent last-ditch equivalent is for Java, or in Unix.