Error Trapping and/or Exception Handling

[brentoboy]

Wow, there are too many schemes to choose from.
c, c++, Pascal, BASIC, VB, java,
Everything has its own scheme.

BASIC's error handling scheme is by far the worst.
It breaks good programming rules by using the "goto" and "jump back" spaghetti code model.  And it is inconsistent with itself.

The "powerful" part about c++ catching errors of any type, and letting the errors be differentiated by what type they are is well written, but WAY OVERKILL.  If you actually used it to catch several possible different error types, it would result in tons of structure code - and a slow end result.

Lets face it, when you get an error, all you need is the error code, so you can do something about it, or admit that you cant do something about it and pass the error on.

the c way (at least with windows structured exception handling) is also gross.

I hate to reinvent the error trapping wheel here, but everything we have to base error trapping on is either long winded, or it has structure that doesnt read well.  Or it uses confusing words, which to a newbie dont imply error trapping at all - like "catch and throw", the first time I saw those, I scratched my head and asked "what could that possibly be?"

Here is the most intuitive error trapping syntax I can come up with.

Try
  [block of "protected" code]
OnFail
  [block of code to run if you run into a problem]
Finally
  [block of code that runs at the end no ...
   matter what happens]
End Try

You can "crash" out of a try block calling Fail(ErrCode)

-Any comments?

[brentoboy]

inside of an OnFail section, we should allow for a ReTry statement that loops back up to the beginning of the Try block and starts over.

[brentoboy]

I am starting to believe that you should be able to include a string telling what you were in the middle of as part of a Fail statment.  so we would call it like one of the following:

Fail(ErrCode)
Fail(ErrCode,"I was trying to access the A: drive")

[brentoboy]

The most important thing about error handling is not really how you trap errors, but what happens when errors dont get trapped.

What does the resulting "Abnormal Termination" message box look like?

APe compilers / interpreters need to make sure that the error codes include lots of info about where you are in the program.  The debug build should tell you what line number of what function you crashed on, what the error was and the call stack from there down to final crash. Complete with all the Fail Descriptions posted by the code doing the work.

"An unhandled exception has occurred in this application, and unfortionatly, it was unable to continue as a result.
Application:  MyProgram.EXE
Module:  Files.Module
Function: File.Open()    [Rev 1.1]
Parameters: path="A:\SomeFile.txt", open_mode=FILE_OPEN_READ_ONLY
LineNo:7
Error Code: 75
Description: Path Access Error
Notes:  I was trying to access the A: drive
---------------
Called by:
Function: DoSomething()   [Rev 1.13]
Parameters:  ...
LineNo: 53
-----------------
Called by:
Function: Main()    [Rev 2.7]
LineNo: 10
-----------------
Build: 0.95.1112
Time: 1/2/05
----------------

I mean really, give me some info about what happend. No one cares how big the debug exe is.  We really want helpful errors, thats all.