tags:

views:

136

answers:

5

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

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

So, to sum up, in a program, you has 2 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 it 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 imcritical error? Just got very curious because i think this concept is very fundamental.

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

+1  A: 

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

Heinzi
A: 

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.

Grzenio
+4  A: 

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.

Jeff Storey
Not quite right. In Java, you have *got* to handle a checked exception either by handling it with a catch or by explicitly declaring that the method allows it to be thrown up the stack.
JeremyP
@JeremyP, that's what I meant, but I'll update the post to clarify the text.
Jeff Storey
checked exceptions may be helpful for small projects, but a bad idea for large projects.
sirmak
@sirmak, I don't think that's a fair blanket statement to make. Both checked and unchecked exceptions can have their places, though I tend to favor unchecked, but I don't think it is necessarily related to the size of the project.
Jeff Storey
@jeff, http://www.ibm.com/developerworks/java/library/j-jtp05254.htmlRecently, several well-regarded experts, including Bruce Eckel and Rod Johnson, have publicly stated that while they initially agreed completely with the orthodox position on checked exceptions, they've concluded that exclusive use of checked exceptions is not as good an idea as it appeared at first, and that checked exceptions have become a significant source of problems for many large projects.
sirmak
@sirmak, I'm not disagreeing that they can become problematic on large projects. They can also become problematic on small projects as well.
Jeff Storey
@jeff, I think you're right
sirmak
+2  A: 

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.

Dr Herbie
Totally agree - in most cases (pretty much everything except OutOfMemory and StackOverflow) it should be up to the calling code to decide whether an exception is fatal or not!
Dan Puzey
A: 

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.

Cylon Cat