Ivica Brodaric wrote:
>I didn't want to start a war of words about a poor little Signal, but I cannot
>resist now. SIGNAL should be used only if you want to branch to a piece of
>code from which you will never come back. In other words, it should be
>reserved for *abnormal* changes in the flow of logic. Error handling is fine.
>Anything else and you are in danger of creating a dreaded spaghetti mess.
<snip>
Admittedly Ray's original post contained some less-than-optimal code, but it's
short and not general-purpose. What's the point of excoriating him for it?
We all (most of us) remember the GOTO-less programming fad. And we've all seen
and heard horror stories in both directions. Neither applies to this example.
Getting all hot and bothered over code this trivial seems, well, overwrought at
best.
Used carefully, SIGNAL can greatly *increase* readability. Richard's example of
a single piece of code that gets called in multiple, wildly varying ways (EXEC,
Pipes filter, XEDIT macro) is one. If I see (p-code):
if pipes signal Pipes
if xedit signal Xedit
<EXEC path>
I don't have to think about what happens after the Pipes or XEDIT processing is
done -- as opposed to:
if pipes call Pipes
if xedit call Xedit
if exec call Exec
Even if (as seems likely) the next line is "exit rc", I now have to think about
how rc is set in each routine, etc.
The same applies to "one entry, one exit": this is more important in languages
where memory management isn't automatic, but even then, going through torturous
methods ("while (0)" comes to mind in C) doesn't always make for the most
readable code.
Another great use for SIGNAL (and one that your rules do admit to) is for error
exits. I hate code like this:
address command 'somecmd'
if rc <> 0 then do
say 'That was an error, rc='rc
exit rc
end
Far better IMHO is:
address command 'somecmd'
if rc <> 0 then signal Error
This keeps the mainline more compact and readable, and it's pretty clear to the
reader that "Hey, we're going somewhere to handle the error and we ain't comin'
back"!
We now return you to the actual thread on SFS.
...phsiii
