TCL error system
Googie
TCL has got really nasty error reporting system (meaby I'm wrong and it's
not foult of reporting system but TCL core).
Is it possible to make TCL working like all commands are executed with
'catch'? Becouse all errors, even smallest, makes whole applications
doesn't work. It sucks! Small errors are not so important that there is
required stopping whole application. Is there any way to ommit it?
--
Googie
Michael Schlenker
> Hi!
>
> TCL has got really nasty error reporting system (meaby I'm wrong and it's
> not foult of reporting system but TCL core)
> 'catch'? Becouse all errors, even smallest, makes whole applications
> doesn't work. It sucks! Small errors are not so important that there is
> required stopping whole application.
> Is there any way to ommit it?
There is no simple way you can stop those small bugs (i assume you mean
things like missing {[]}"" , small typos in proc or var names, argument
mismatches for procs and the like) from stopping your app. Those are
small for your app, but major for the tcl core (unless your talking
about a Telepathic Computer Language ;-) ), it simply cannot see what is
wrong.
Use static syntax checkers like frink or procheck for simple syntax
checking, to find bugs sooner. An editor with working syntax
highlighting may help too. tcltest is worth a look too, as is test
driven programming in general.
You can always add [catch] in appropriate parts of your program, but
catching all commands is somewhat pointless (unless you like things like
pointers to already freed memory, overflowing buffers and other nasty
bugs common in C/C++).
Michael Schlenker
Derk Gwen
# Hi!
#
# TCL has got really nasty error reporting system (meaby I'm wrong and it's
# not foult of reporting system but TCL core).
# Is it possible to make TCL working like all commands are executed with
# 'catch'? Becouse all errors, even smallest, makes whole applications
# doesn't work. It sucks! Small errors are not so important that there is
# required stopping whole application. Is there any way to ommit it?
You can do something like
foreach command [info command] {
rename $command /kimble/$command
proc $command args [list catch [list eval /kimble/$command $args]]
}
but it be better to catch specific errors you have determined are needless.
--
Derk Gwen http://derkgwen.250free.com/html/index.html
I ASSURE YOU WE'RE OPEN!
Bruce Hartweg
Only the application itself (and you, the app developer) can know
if an error is important or not. TCL is a language that provides
the mechanism for handling all errors, whether big or small, it
is your job to handle them appropriately.
if [set ...] fails, only *you* can determine if that is serious
or not. for example:
if {[catch {set pet $name}]} {
set pet "fluffy"
}
if {[catch {set name [findImportantFile]}]} {
tk_messageBox -massage "Very Important File is missing - See Admin"
}
in one case - it is not that bad, but *you* need to determine that
you can recover from that error, in the other it is very important,
but still better for you to handle the error & present a message
that is meaningfull to the user.
Bruce
Vincent Wartelle
There is no simple way you can stop those small bugs (...) from stopping your app.
Arjen Markus
Actually, I think it is one of the great strengths of Tcl that it warns
about this type of things!
I will explain this:
- In C it is all too easy to refer to memory that has been freed. There
will be a coredump in the best of cases or a silent memory corruption
if you are unlucky.
- Unless the compiler can find it out via static analysis (or special
run-time handling), many languages will be very happy to work with
uninitialised variables:
y = 1;
x = x + y ;
printf( "My array-element is %d\n", array[x] ) ;
The outcome (certainly in C or Fortran) can be anything. Many a time
(especially during your in-house testing) the value of x before the
second statement will be 0, possibly/probably giving you what you
want.
Only when it is shipped to several hundreds of clients, the error
will surface: x is suddenly defaulting to -1323423 and you are way
outside your array.
Run-time checks are your friend!
Regards,
Arjen
lvi...@yahoo.com
According to Googie <do...@want.a.spam.org>:
: Becouse all errors, even smallest, makes whole applications
:doesn't work. It sucks! Small errors are not so important that there is
:required stopping whole application. Is there any way to ommit it?
What kind of small errors are not so important?
Certainly, any time you do an exec (or probably an open) you should do
a catch.
For these types of things, why not write your own procs (my::exec and
my::open) where you do the catch and handling safely, and then just call
them each time you need to perform these functions?
--
Tcl - The glue of a new generation. <URL: http://wiki.tcl.tk/ >
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lvi...@yahoo.com > <URL: http://www.purl.org/NET/lvirden/ >
Googie
> Actually, I think it is one of the great strengths of Tcl that it warns
> about this type of things!
Ok, I agree that TCL warns, but why it stops whole (or big part) of
application? Long time ago I wrote lot of scripts for EPIC4 and in its
scripting language, user is noticed about errors, but whole script is still
workinkg.
--
Googie
Cameron Laird
It's hard to know what kind of answer will satisfy you.
At base, no one has both believed the kind of change you
describe is sufficiently desirable, and had the ability
to implement the change, for it to happen.
You might like to learn about Tkcon. I suspect you'd
enjoy running your applications within Tkcon, and having
access to script state after an unrecovered error.
--
Cameron Laird <Cam...@Lairds.com>
Business: http://www.Phaseit.net
Personal: http://phaseit.net/claird/home.html
km...@socrates.berkeley.edu
You are talking about a fundamentally religious question to which
there is no correct answer, or rather all answers are correct in
some situations. That question is what to do when the system detects
an error.
On one extreme, the one you seem to want, is to fix the error as best
as possible and continue on. This is what you want if you're writing
code to control the Mars Rover (for a fascinating article about
exactly that see http://catless.ncl.ac.uk/Risks/19.49.html#subj1).
The other extreme is to abort on almost any error--something's
wrong and the user must be notified to fix it. This is the approach
that compilers often take, and, in retrospect, the one browsers
should have taken vis-a-vis HTML parsing.
In general, something in between is usually what's done but exactly
where depends on your application, your audience and your own
personal preference.
Fortunately, tcl has the mechanism to let you choose where on the
spectrum you want to be.
Keith
Chang Li
<km...@socrates.Berkeley.EDU> wrote in message
news:b2brve$1l2p$1...@agate.berkeley.edu...
>That question is what to do when the system detects an error.
There are static and runtime errors. The static errors include syntax errors
and typing errors.
The better way to correct the static errors is to find them all in one pass.
Then you can modify
them all with an editor. The runtime error need to be corrected one after
another. Current
using of Tcl does not distinguish the static and runtime errors. I usually
got boring when I
figure out a syntax error and run again to figure out another typing error.
Compare to C++
compiler it could find almost all the syntax errors in one pass, you may
feel discourage.
I do not know the solution in the Tcl level. But in the C level of Tcl we
can add many error
checks such as type checking and Tcl can report the errors.
Chang
Gerald W. Lester
Your scenario works for C, but Tcl can create new procedures at run time
as well as redefine the syntax and semantics of existing procedures at
run time.
Of course you may argue, "you should not create procedures at run time"
-- that is a "personal opinion. My personal experience in creating
24x7x52 systems is it is invaluable to be able to create/redefine
procedures while the code is running.
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester | "The man who fights for his ideals is
|
| Gerald...@cox.net | the man who is alive." -- Cervantes
|
+--------------------------------+---------------------------------------+
Kevin Kenny
I do not know the solution in the Tcl level. But in the C level of Tcl
we
> can add many error
> > checks such as type checking and Tcl can report the errors.
> Your scenario works for C, but Tcl can create new procedures at run time
> as well as redefine the syntax and semantics of existing procedures at
> run time.
>
> Of course you may argue, "you should not create procedures at run time"
> -- that is a "personal opinion. My personal experience in creating
> 24x7x52 systems is it is invaluable to be able to create/redefine
> procedures while the code is running.
Which isn't to say (speaking as another Tcl coder with 24/7 systems)
that you don't run the code through Frink or procheck before loading
it. In other words, if you want more static checking, you know where
to find it.
The last couple of obscure runtime errors that bit me were unexpected
octal.
--
73 de ke9tv/2, Kevin
Ceterum, censeo: numeros octonarios delendae sunt.
Gerald W. Lester
>
> Chang Li wrote:
> I do not know the solution in the Tcl level. But in the C level of Tcl
> we
> > can add many error
> > > checks such as type checking and Tcl can report the errors.
>
> "Gerald W. Lester" wrote:
> > Your scenario works for C, but Tcl can create new procedures at run time
> > as well as redefine the syntax and semantics of existing procedures at
> > run time.
> >
> > Of course you may argue, "you should not create procedures at run time"
> > -- that is a "personal opinion. My personal experience in creating
> > 24x7x52 systems is it is invaluable to be able to create/redefine
> > procedures while the code is running.
>
> Which isn't to say (speaking as another Tcl coder with 24/7 systems)
> that you don't run the code through Frink or procheck before loading
> it. In other words, if you want more static checking, you know where
> to find it.
Of course, just like you run C/C++ through link and a memory checker
(e.g. Purify).
lvi...@yahoo.com
According to Chang Li <cha...@neatware.com>:
:There are static and runtime errors. The static errors include syntax errors
:and typing errors.
:The better way to correct the static errors is to find them all in one pass.
Well, that's certainly _one_ way to do things. 'Better' is in the
eye of the beholder.
:Compare to C++
:compiler it could find almost all the syntax errors in one pass, you may
:feel discourage.
I don't know about C++, but certainly in C I often found cases where
fixing one set of syntax errors complained about by the compiler revealed
a new set that had not yet been reported.
:I do not know the solution in the Tcl level. But in the C level of Tcl we
:can add many error
:checks such as type checking and Tcl can report the errors.
There are tools such as procheck/frink which you can integrate into your
development environment to do these checks.
However, many interpreters do not do a pass over the entire application
looking for errors. Instead, they expect the developer to check for that
before deployment, so that the startup time for the application can be
reduced.