A Novel Approach to Exception Handling

A Novel Approach to Exception Handling

• sjkepner

  I'll take a detailed look at this when I get home tonight. Always nice to see new ideas

  
  
  

• yanivpinhas

  Well, the articles were hard to read with my limited english skills (and hurry) :) But I post a comment anyway:
  
  Did I understand correctly, that the "side effect of unexcepted exceptions" is coming from catching too high level exceptions, or using exception handling as a program flow mechanism All good .NET books warns about these things. But does the .NET have to have a specialized mechanism against the developer based errors If programmer cannot use exception handling correctly, can he/she use mechanisms that fix the problems caused by himself
  
  Programmer should always know what to except to go wrong. If the "wrong" type of exeption comes in the high level, the problem is in the deep, not the top. Most top level catch block should catch only what is excepted, so that all others exception types makes the program die. If programmer does not know what can go wrong, he must not handle the exception.
  
  These kinds of mechanisms sounds too much like a plaster than a solution to me: if the problem is in the deep, why try to fix it on the surface You definetly shouldn't let the bottom level errors to get to the products. After all, if the exception handling is done in the most specialized way (by using the most appropriate exception type in catch blocks), isn't the program killed every time unknown exception occures
  
  
  "Another candidate for such notation is unbreakable"
  I couldn't code a thing because it reminds me too much of Bruce Willis :)
  
  

• NoobestNoob

  Hello Rauhanlinnake!

  I've found you’ve understood the problem some another way. I’ll try to explain what the side effects may exist.

  In .NET exceptions serve as a base of error handling. Every method (and even some instructions) may potentially throw an exception (which is documented or non-documented exception type). We actually expect some situation and provide corresponding guards and handlers in those places, where they may actually to occur (in our developer’s scenario in mind). Also we can hope that if something unexpected is not handled at some level, let an upper level handle this problem. All looks well, but the two following insidious things may take place:

  1) Implicit interruption of one or more intermediate levels (these methods can perform some logically unbreakable operations which stay incomplete, that potentially can cause an inconsistent program state, unrecoverable result);

  2) A misidentification of this unexpected exception (originated from the depth) at the upper level. This upper level may treat such exception class as a normal case, implying that its nearest lower-layer methods (it relies on) do actually throw such classes.

  Exceptions serve as a basis of error control, but they have a grate influence to the code flow and implicitly may break some critical places. Also they may be erroneously caught by handlers, which consider them in incorrect way. Such insidious situation may occur in a well tested program under some odd conditions, when customary application’s environment changes (low system resources for instance, or another international settings). Such behavior takes a place not often, but this potentially may occur and some day will corrupt program result in a very strange form. All is said regarding to unexpected exceptions only.

  Error handling, in general, is a very hard thing. In result-code-based strategy (such as used in Win32) we have to specify a lot of checks in order to ensure reliable result. Negative side of this strategy is that we can not safely omit error checking. Exceptions solve this problem — they serve as automation of error checking by throwing errors as exceptions, but this automation also has a shortcoming — the Side Effect of Unexpected Exceptions. No painless solution exists in the problem of error checking! Java’s checked exceptions are a solution of course, existing solution, but this was named as “handcuffs” in respect of C#.

  Side effects may also be caused by some consistency harmful exceptions like StackOverflowException (which became fatal in .NET 2.0), OutOfMemoryException, AccessViolationException, ThreadAbortException, ThreadInterruptedException, etc. They may be occasionally caught by the most general catch block, or by catching SystemException, when you actually do not suppose such a situation. It is very difficult in some cases to avoid catching of consistency harmful exception, because all above listed classes are descendants of SystemException, and you have to enumerate all your expected exception types (not simply catching SystemException). I think that this is not right to allow catching consistency harmful exceptions by the normal catch block! It is very sad that there are no constructions like catchrisk or catchall section to serve specially for such dangerous tricks.

  General programming language is applied to different areas; some of them are very critical to unexpected errors. In my novel strategy all that is unexpected will be handled as fatal, killing entire application domain. Unbreakable code is a severe solution of the problem. A compromise is required. Regarding to default compilation settings I propose to use unbreakable code partly — only there, where unbreakable blocks were manually placed. For compilation of error critical code there is a need in some compiler option to control its default unbreakability (/unbreakable for instance); also there is a need in the two following special directives: #unbreakable and #endunbreakable (for example).

  Sergei Kitaev

  
  
• A Novel Approach to Exception Handling