Where exactly are we GOING

var  number, zero: Integer;
begin    // Try to divide an integer by zero - to raise an exception
  Try
    zero   := 0;
    number := 1 div zero;
    ShowMessage('number / zero = '+IntToStr(number));
  Except
    ShowMessage('Unknown error encountered');
  end;
end;

I like StrToInt, but it causes an exception.. so I am going to invent a better function for dealing with converting strings to integers, using no exceptions! But, errrr, wait, I thought the whole point of delphi was that it had exceptions, and that was one of its advantages.. so, why am I avoiding the use of exceptions and creating a better function, TryStrToInt, when obviously exceptions are superior to error codes? Err... hmm.. maybe exceptions are not all that they are cracked up to be... because errors are, not, um.. exceptional.. but expected to happen in programs? Err wait did I just reinvent the old turbo pascal Val() function... under a new name.. TryStrToInt.... Oh yes I did, because, exceptions are so good that i have to work around exception by inventing new functions that don't use exceptions but return proper errors that I can deal with in the code. Err.. hypocrisy? Oh well, back to coding! Exceptions are so great! Old C programmers who return errors are behind the times. Ugh, but isn't that what TryStrToInt does that I just invented and is now commonly and standard for delphi programmers to use in place of StrToInt...

The keywords "try" and "finally" do not show the programmer what errors are anticipated from what functions.. they sort of appear to make a "guess" of what group of functions could cause errors and "cross fingers hope for the best"! It is never clear as to whether all the code has been checked or cleaned up properly. Even worse, if you put a try finally there, it makes it look as though you have done something right, when in fact you don't know for sure. It gives you a false sense of hope.

In fact, every single function may need a try except or try finally wrapped around it in some way or another, to be safe.. - but this would be verbose - so programmers simply don't bother putting enough try except or try finally blocks in their code, since less is easier.

Try and Finally blocks are a form of a limited GOTO (intraprocedural?) statement, and they force code to be nested in unnatural ways at times (with no labels of what is being GOTO'ed). Try is the same as Try. That's an important bonus of the EVIL GOTO statement.. the fact that one can describe where he is GOING and WHY he is going - we aren't making guesses here, we are specifically routing the code to structured blocks - it couldn't be more structured. Proper use of GOTO statements can act like a CASE or EXIT statement.

Go Out Now

Structured programmers may argue that nests (even if deep) are always better than GOTO's no matter what.. but the reality is many times in programming we want NOTHING TO DO with bad inputs.. and going through a nest would only cause hazard (in case the nest makes wrong assumptions or in case there is an error in the nest such as an AND not being an OR). The lie that nests are always better than GOTO's are only supported by religious groups.

However, instead of using GOTO, my technique should still rather be implemented as a language feature (a limited goto, like exit and break, but with more benefits). This is a specific technique, and specific techniques should not use extremely flexible controllers like GOTO's.. if possible. Unfortunately, right now, languages don't implement the feature I need, and GOTO is the clearest and cleanest solution. As long as articles and source comments are written clearly, the use of GOTO can be okay while we wait for the proper feature to be implemented for the technique I describe below.

Gotos Harmful?

We need a limited goto that can only go down, like the exit statement, but with ability to execute a error code block.. no, i'm not talking about exceptions, this is different.. exceptions are upstream "raises" that are like intraprocedrual gotos).

If you think I'm on crack for agreeing to use GOTO statements in some situations, then please read some of Knuth and Wirth's earlier material. Knuth and Wirth generally think unstructured GOTO programming is bad, but RECOMMEND using GOTO statements when used properly. Niklaus Wirth recommended using GOTO statements when they are used for the right situation.

The problem is that lots of people don't use GOTO's properly, so this is why for example Wirth started removing many GOTO features in his languages, and this is why Goto Considered Harmful was written.

Everything Considered Harmful

Wirth and Knuth are not religiously against GOTO statements, they are religiously against poor use of GOTO statements. Wirth and Knuth recommend using GOTO statements when the GOTO flow goes from top down (i.e. one should try not to jump up, although CONTINUE does).

Using a Good GOTO

procedure algorithm(s: string; num: integer);
var
  local: integer;
label 
  error1, error2, error3;
begin
  if s = '' then goto error1;
  if num = 0 then goto error2;
  
 { important algorithm code goes here }
  //... 
  //... 
      // some nest....
      if local > 60 then goto error3;
  //... 
  //... 

  exit;   { unless there was an error! }

 {----------- keep errors together in a structured area -----------}
  error1: 
    begin
      {$IFDEF VERBOSE_DEBUG}debugln('error 1: string is empty');
      {$ENDIF VERBOSE_DEBUG}

      {$IFDEF DEBUG}debugcode(1);
      {$ENDIF DEBUG}
      exit; // all errors must have a single exit point!
    end;

  error2: 
    begin
      {$IFDEF VERBOSE_DEBUG}debugln('error 2: num parameter must not be zero');
      {$ENDIF VERBOSE_DEBUG}

      {$IFDEF DEBUG}debugcode(2);
      {$ENDIF DEBUG}
      exit;
    end;

  error3: 
    begin
      {$IFDEF VERBOSE_DEBUG} 
       debugln('error 3: 301 redirect recurisive limit of 60 encountered');
      {$ENDIF VERBOSE_DEBUG}

      {$IFDEF DEBUG}  // messy debug IFDEF's don't belong in the algorithm, they can
       debugcode(3);  // be placed here instead. A form of data hiding. One can
      {$ENDIF DEBUG}  // still see this code on his screen below the algorithm 

      exit;
    end;
 {-------------------------------------------------------}
end;

In the above code, we see that the "IFDEF DEBUG" is verbose and messy.. so using GOTO statements allows the IFDEF messy code to be hidden from the algorithm core code.

The algorithm core code should be kept clean, and should if possible avoid messy IFDEF kludges. Yet, sometimes, in large software programs, we must use conditional IFDEF's for things like extremely verbose debugging. Yet some programs do not require extremely verbose debugging, and only terser debug messages are required.

If those IFDEF conditionals were placed in the core algorithm code, it would be very messy, and the algorithm would become less readable. Yet, a clean and easy solution is to simply move the IFDEF code out into a nice separate structured area.. underneath a label. This, is structured GOTO programming, rather than unstructured GOTO programming.

Z505 Theory: Logging Serious Applications is Critical

When things go wrong, what do we usually do? Unwind, cleanup, log, and exit as soon as possible, notifying the caller of an error through function results or exceptions. And don't forget, even if I mentioned it already, to log the early exit! Logging the end of the function isn't enough - because exit statements don't hit the end of the function. GOTO statements allow one to exit the function AND log the exit, a big benefit over the more simple EXIT function. One could insert the debug log code in the algorithm instead of using a GOTO, and then EXIT after sending notes to the debug logs.. but this pollutes the source code with debug logs and exit statements and parenthesis and begin/end pairs.. sometimes, GOTO ERROR allows the code to remain much cleaner!

The method I use above with GOTO statements allows us to cleanly log our difficulties and exit the function. I say cleanly log our difficulties because our core algorithm remains clean and readable, while the messy but extremely important DEBUG calls and IFDEF conditionals are stored away from the algorithm (yet, not so far away from the algorithm that it becomes hidden.. rather, one only has to scroll down to the clearly labeled and easy to find code block.. as opposed to the logging being hidden somewhere else upstream or hidden in some internal compiler automatic error message system).

Logging, is extremely useful - and all important systems should be logged. Log files can be analyzed after problems have occurred. Users of software rarely have time to report bugs, and are rarely motivated enough to report bugs. Even programmers themselves have difficulty reporting bugs. But if there is a log file and an audit trail available, it makes it much more easier to see what happened.

Logging also makes it much easier to debug programs that have gone awry and wrong on someone else's computer in some other country, where remote debugging is not feasible or possible (i.e. a user or customer may not allow you to remotely debug a program on his computer or server, and a user or customer may simply be too lazy to offer you this opportunity.. yet if you ask the user or customer for a log file that has already been automatically generated, he will be more than willing to send it to you since it is so easy and convenient to do so).

Unlabeled Try Finally Nests Harder to Understand?

  if s = '' then goto LOCAL_ERROR1 

With a try finally block, it is not always clear WHAT ERROR we are cleaning up from, because the error we are trapping could be some hidden unknown exception in the upstream code (how do we know what will be raised, when writing new code with an unfamiliar library? an error in a function declaration can be anticipated, so how do you anticipate an exception for un familiar libraries?). This breaks the contract! In order to obey the contract in programming, we must know what we are trapping or what we are doing!

One could add source code comments saying "this try block cleans up all errors such as when the string is empty and when the integer is invalid".. however, not once in my entire programming life have I seen a programmer comment his try finally blocks like this.. plus, these comments become more verbose than just using descriptive Labels.

I think maybe since GOTO has such a bad reputation, programming languages should introduce a specific GOTO statement for ERROR's, just like how BREAK and EXIT and HALT and are specific GOTO statements for breaking out of a loop or procedure or program.

Instead of GOTO.. it could be called EXIT_ERROR or EXITERR, and it could limit the program to only go DOWN rather than UP (i.e. the CONTINUE is an upward GOTO and would not be permitted or part of the EXITERR feature).

Just like how EXIT is limited to exiting a procedure and not traveling upward, the EXITERR feature would limit the programmer to only exit the function with a labeled error.

Nesting Messing

GOTO statements, if used with care, are actually easier to understand and code than a nest of Try Finally blocks in some cases. Nesting try/finally blocks is just another way of using GOTO statements without precise labels.

With a goto statement, one can write a GOTO ERROR_XYZ anywhere in the algorithm, meaning no ugly NESTS in many cases. I'm not talking about intra procedural GOTO's (which HALT is) but rather just talking about LOCAL GOTO's. However, even intra procedural GOTO's can be useful - such as HALTING a program from within a procedure.

Halt, or Exit?

Sometimes we cannot see where the exceptions are going to occur in program code. GOTO statements, if used properly, can show us precisely where our rollback or exit or halt is going to occur. Try finally nests sometimes send us on a wild goose chase, like deep nests do. My point is that sometimes clean and clear GOTO statements are sometimes much more readable than nested try finally blocks.

Is an Exception an Invisible GOTO in Some Cases?

Documentation rarely mentions how one is suppose to enclose his code in try finally or except - they leave it up to the creative thinker! Sometimes it is Try/Except, other times it is Try/Finally. API's don't always mention that certain exceptions are going to occur if XYZ activity happens too. Documentation writers make mistakes and skip important details some times. Upstream libraries sometimes assume that they know where exceptions should occur and that everybody downstream is an idiot. Making assumptions isn't such a good thing always. For these reasons, sometimes function results, debug logs, and GOTO statements are cleaner than religiously using exceptions or finally's for everything.

And if you think I'm on crack, then please consider the fact that:

• If try/finally/catch/raise/except were clear, structured, and if they were the holy grail, there wouldn't be so many disputes and arguments about them

• Knuth and Wirth recommended the use of GOTO statements in some of their books, they just didn't recommend using GOTO's in bad form

• Linus Torvalds, Raymond Chen, and Joel Spolsky find exceptions hard to understand... and these are some pretty smart programmers. I don't agree with what everything Linus, Raymond, and Joel say. I agree with a lot of things Joel and Raymond say, and only some things that Linus says.. but we agree that exceptions are very hard to understand at times.

• Unfortunately, religious Delphi Zealots probably read my wiki.. and I know they just love exceptions. I hate to burst your little bubble. Keep an open mind.

• exit, halt, and continue are all goto statements.. they are descriptive labels telling the programmer where the function or program is GOING TO.

• if you were stuck in a maze starving to death, and you were offered a GOTO statement which led you to the end of the maze immediately (and a food stand existed outside of the maze), you would take it without hesitation.

What is Exceptional

For example, if a File Does Not Exist, is this an exception, or is this a logical boolean error that can be handled with an IF statement?

It depends.. if the rocket is going to crash because there is a missing file in the memory drive (or whatever rockets use for data storage) then this might be an exception.. but in other cases, like desktop software.. it isn't an exception. Exceptions, give Upstream library writers too much room for assumption. If we assume it is exceptional that a file does not exist, someone downstream of us may not think this needs to be exceptional.

There is controversy of what an exception is and when it should be used. For example Prof. Andrew P. Black. in his Doctoral Dissertation states that:

"The definitions used by the designers of various exception handling mechanisms are compared, but none is found to be satisfactory."

Proposed Solution for Z505 Debug Technique

The verbose debugging and IFDEF conditionals for logging belong in a nice separate area that is clearly labeled. This area does not have to be a GOTO LABEL area, it rather can be a restricted EXITERR area that is specifically designed for exiting the function and logging the exit appropriately.

Many programmers ignore debugging and refuse to offer debug logs in their applications simply because current languages make it too hard to exit a function cleanly with debugging on. Debugging applications using writeln('log this') in a clean manner in current languages involves messy {$IFDEF} conditional code obfuscating the core algorithms. The ifdef is to turn debugging on or off at compile time but it pollutes the source with ifdefs. A new language construct is needed if we are to reduce GOTO statements and improve logging ability.

The techniques described in this article by Z505 software are a form of restricted GOTO use, and in order to restrict the GOTO even further, this technique needs to be implemented into the language as a new keyword/construct, just as EXIT, HALT, BREAK, and CONTINUE are restricted forms of GOTO.

Documentation Regarding Exceptions is Confusing

Since documentation generator tools also do not pick up exceptions and explain where they are going to be raised (it would have to know everything about your code), even function error codes may be more clearly documented than exceptions hidden away inside the code blocks of the algorithms. In Delphi, exceptions are sometimes documented but then the except clause is not recommended by several delphi experts and only an unlabeled and non-descriptive try/finally is recommended.

Try/Except offers a label system but yet try except is vigorously discouraged among several programmers - as it is unclear whether a custom exception is a good idea. For example, a Delphi expert, Rudy V. is even unclear himself about whether it is wise to use Try Except.. and says that he is "not sure if it is a good idea" in a newsgroup posting. Many other Delphi experts advise people not to use try except, while others advise programmers to use try except. Not only is the documentation confusing, but the newsgroups and third party advice on exceptions is too.

Since try/finally blocks are not labeling which errors they are catching, this hides a contract, or hides what condition is being tried and what condition is being finalized (one can sort through the code in between the try finally block, but it is not clear how many nests inside that try finally block must be added, nor is it clear how many errors are going to be raised in the try finally block, nor is it clear which functions could be producing the errors that will be sent to the finally block. Basically, the exceptional circumstances are unlabeled, and not described in the code.

Basically exceptions are saying: Out of site, out of mind. Ignorance is bliss.

"Exceptions are only generated in the expectation that they will eventually be handled. For this to be possible, a routine which can generate an exception must declare this fact as part of its specification. Full details of all of the consequences of the exception must be provided if it is to be handled effectively. " --Prof. Andrew P. Black, Doctoral Thesis

Your only hope is the documentation explains all the consequences of the exception and when it will be raised, which is never the case. Documentation just briefly and tersely skims over the exception issue further down the page (not in the function declaration) and gives you a general warning when an exception will occur (glosses over it), but you don't always know when or how it will occur exactly, and there is no official contract! One option is to literally read through all the source code of the library you are using and figure out what and when a raise will occur, which is time consuming, and you probably won't get it right. Exceptions are hard to get right, whereas an error contract makes it obvious that errors will occur. With error contracts you can expect to recover from errors logically, without pretending everything will just get cleaned up and work out okay with a finally block)

"If you have failed the contract, then an unexpected situation has arisen -- it is fundamentally IMPOSSIBLE to program for unexpected situations. Let me restate that: It is impossible to handle unexpected errors!

The only errors that you can handle are EXPECTED errors, and in that case they should be written into the contract. " --Taylor Hutt, Usenet Post

"Forcing the calling code to handle the error right away is the correct approach, because it forces the programmer to think about the possibility of an error occurring. That's a key point. The fact that this clutters the code with error checking is unfortunate, but it is a small price to pay for correctness of operation. Exceptions tend to allow, even encourage, programmers to ignore the possibility of an error, assuming it will be magically handled by some earlier exception handler."
http://www.lighterra.com/papers/exceptionsharmful/