Re: Runtime Syntax Checker

On Dec 6, 2:04 am, "Donal K. Fellows"
<donal.k.fell...@xxxxxxxxxxxxxxxx> wrote:
tom.rmadilo wrote:
But if the script was not a loop, the enclosing command converts the
[break] into an error. Unless there is a surrounding [catch], nothing
will prevent a [break] executed outside of a loop from being
converted into an error.

Nothing? Not even a Tk binding handler? (Please be careful with those
generalizations!)

Never say never! Maybe I should concentrate on facts and avoid nevers.

If any Tcl command sets a return code other than zero (0), the current
script execution is aborted. The caller decides what to do next. If
the caller is unprepared to handle the non-zero return code it is
translated into an error.

The Tk binding handler is not unique. It acts like a typical loop,
with each matching binding executing. A [continue] causes the current
script to abort, but any following scripts will execute. [Break]
causes the expected total abort. So it is obvious that the Tk binding
handler operates as a loop, and acts like a loop. So a Tk binding
handler is a loop.

[Catch] has nothing to do with control code.

It has as much to do with control code as [expr].

Something must not be getting through to you guys about Tcl. The
language was designed as a safe language. Something which would keep
you out of trouble, keep you from making stupid mistakes, like letting
an error go unhandled. In C, you can ignore errors, execution
continues. Tcl provides [catch] which can be used to get you back to C
unless you know what you are doing.

As far as examples go, all I can say is that I have probably more
lines of code than found on the wiki, yet only a few lines use
[catch]. Each use of [catch] is easy to interpret from the local
context, and is not part of a non-error-recovery control structure.

The possibilities are not brain surgery or rocket science. Every
command which sets a non-zero control code forces the enclosing script
to abort. The caller must then handle the exception. If the exception
is unexpected, the likely result is an error. For C level commands,
handling exceptions is easy. But on the Tcl level you have to use
[catch]. And every use of [catch] used as a control "gear" must handle
every possible exception...correctly. Otherwise you have a rogue
operation where important information is lost. A poorly executed
[catch] is like a yes man, telling their boss what they want to hear.

So every Tcl command has the same directive: handle expected return
codes by design and turn all others into errors. The lifetime of a
real non-zero control code is very short, and those outside [error],
[return], [break] or [continue] are unimpressive, they burden [catch].
Maybe blame [catch] which works so well...it invites abuse.

From my perspective the abuse of [catch] is unimportant. I never use
[catch] over unknown code to feed a controller. Unknown code is either
pass or fail. So every opaque command I call is subject to this
requirement: it either succeeds or fails. Opaque commands cannot
return more information to the caller. Any additional return codes
imply prior coordination...which implies a tight coupling of multiple
layers of code. My only question is why couple multiple layers? They
are in effect one layer once you have bound them together. This is the
whole point: send a signal and then catch the signal. Every Tcl
"exception" causes the execution of the current script to abort.
Control is returned to the caller of the script. The value of the
exception (on the C level) is used to direct further execution.
Expected return codes result in command specific behavior, but
unexpected return codes should result in the generation of an error
returned to the caller.

So the lifetime of unexpected exceptions is one (1) unbound,
independent, layer of code. In general each Tcl command defines an
independent layer of code and should be expected to return a defined
and limited set of values and return codes. If you write a Tcl script/
command/proc which generates a distinct class of exceptions (return
codes other than 1,2,3 or 4), the first order of business is to
[catch] these exceptional return codes. You must catch them because if
you don't they will abort the current script and cause an error. The
main problem is that when you [catch] your child script you also
[catch] errors, or essentially any non-zero return code.

This is a typical problem with software. It is easy to assume control
(that's what [catch] does) but then you inherit all the
responsibilities of the built-in controller.

In general there is nothing wrong with multi-layer control structures.
The main issue is the need to coordinate multiple levels of code,
which is unhelpful, if your control structure requires or benefits
from multiple code layers, it would probably benefit even more from an
unspecified number of layers.

Without changing the current behavior of Tcl exceptions I could
imagine that any positive return code caused the current script to
skip any remaining code (as usual). But unrecognized, non-error (1)
return codes (5+) would continue up the stack with their return code
unchanged (assuming the parent command doesn't handle the return
code). The stack trace would remain as useful as that produced by an
error. If the exception reached the global level it would become an
error (it was not handled).

The distinction here is that an exception becomes a generic tool to
escape from some deep computation, but the exception is ignored by the
typical block structures. At the global level these exceptions are
converted into errors. But these errors should not be caught! Instead
these errors direct the developer to the code which needs work in
handling the exceptions at the correct level.

There still exists a coupling of code which generates exceptions and
exception handlers, but the code in-between can remain ignorant of
this communication. Tcl's significant security feature is that it
aborts script execution after an exception. A tiny change which
reflected unhandled exceptions to the caller could solve many
problems.




.

Relevant Pages

  • Re: MATLAB Code for a stop process button which ex
    ... especially in the while loop(for each script command starting in the ... % varargin command line arguments to stop_button ... % line_num is the order of execution. ... msgno = msgno+1; ...
    (comp.soft-sys.matlab)
  • New command execution vulnerability in myPhpAdmin
    ... New command execution vulnerability in myPhpAdmin ... this method assumes that the 'test' table in the mySQL database has ... These evalfunctions are called if the rest of the code in the script executed ...
    (Bugtraq)
  • Re: Embedding a Tclinterp : some pointers requested !
    ... > In our app, various script files using Tcl syntax will ... > - let the user cancel the execution, ... > - when the current command is complete, ... > - it does not allow to stop the interpretation in case of an infinite ...
    (comp.lang.tcl)
  • RE: Rename domain workstations based on Dell service tag?
    ... note that this script displays constructed NETDOM command to execute, ... because, if netdom asks for any input, command window should be visible. ... means-halt execution of script until this command is completed execution. ...
    (microsoft.public.windows.server.scripting)
  • Re: Runtime Syntax Checker
    ... called outside of a loop. ... That error is generated when a break exception propagates beyond the ... What happens when a script reaches a? ... Execution continues at the next command. ...
    (comp.lang.tcl)