Java vs. C#: Checked vs. Unchecked Exceptions
Billy Barrett writes:
I have come to the conclusion that writing a highly robust application with C# is nearly impossible because of [reasons such as...] you are catching the exceptions that are being thrown and then the person who wrote the component you are using adds a new exception. As you realize, they will more often than not forget to tell you and now you won't be handling it.
I can't think of a crisis scenario. At iteration 1, the system is working and handling exceptions A, B, and C. At iteration 2, new exceptions D and E are introduced. D is a subtype of C, an E is a totally new exception, unlike anything that's gone before. Presumably, our code that handles C should handle D just fine. In Java, we can't get a successful compile until we address the issue of E, while in C#, the compilation works fine, but the first time that an "E" is thrown, the system stops. No code breaks that shouldn't, i.e., the only time the system fails is when the system is in a state that generated this new, unlike-anything-we've-seen-before exception, which means that either the system is dealing with a scenario we hadn't dealt with in iteration 1 or our understanding or requirements for the scenario have changed. One way or the other, the code that breaks, should break.
It's important to note that with .NET we do not face the DLL Hell of introducing an iteration 2, E-throwing component into a system that depends on the iteration 1, only-A,B,C-throwing component. The versioning stuff can ensure that if our system is only robust with the iteration 1 A,B,C-throwing component, then our system will continue to use the proper component.
The only scenario where things break down is when I just slipstream the throwing of E, without letting anyone know that I've introduced dramatic new behavior to the system. But do we really want or need a compiler to be the guard against such behavior?
