Ciao Marco
On 11/11/2012 10:17 AM, Marco Pallante wrote:
Hello everyone,
I'm doing some experiment using rivet2.1rc2 and tcl8.6b3, and I'm experiencing a
different behavior in code executed under Rivet and under plain Tcl.
My need is to redefine the ::unknown command to do some magic.
If I call an non existing proc "mytest" under tclsh, I get the message saying
invalid command name "mytest"
Under Rivet, I get the equivalent message
invalid command name "mytest"
while executing
"mytest"
(in namespace eval "::request" script line 23)
invoked from within
"namespace eval request {
puts -nonewline ""
This should continue with other information starting with
OUTPUT BUFFER:
usw.
Which is the output generated by
proc handle_error {} {
global errorInfo
global errorOutbuf
puts <PRE>
puts "<HR>$errorInfo<HR>"
puts "<P><B>OUTPUT BUFFER:</B></P>"
puts $errorOutbuf
puts </PRE>
}
which is the default error handler. You can install a custom error
handler with the ErrorScript directive and in case customize the output
for your needs or fire other code. If the headers haven't been sent
already (usual true while executing BeforeScript) you can redirect the
request to another URL
But now, I use the following code to rename ::unknown to ::_unknown,
and redefine ::unknown
to do some application specific stuff and then calling the original ::_unknown.
<?
# I need this under Rivet because the global namespace doesn't
reset among calls
# and I prevent the original ::unknown to be lost at the second execution
if { ! [llength [info commands ::_unknown]] } {
rename ::unknown ::_unknown
}
Did you try to put this in a ChildInitScript? It should rename the
procedure once for all as long as the interpreter exists
proc ::unknown {args} {
# ... do my stuff ...
# call the original unknown proc using the code seen in man page
uplevel 1 [list ::_unknown $args]
}
mytest
Of course, in the plain Tcl version I just do
rename ::unknown ::_unknown
proc ::unknown {args} {
...
}
mytest
Under plain Tcl, I get exactly the same message then before, and it's what
I expect. The uplevel stuff should put the execution of ::_unknown at the same
stack level than ::unknown, and it's a good thing, because I want to hide the
redefinition.
invalid command name "mytest"
Now, under Rivet, the message changes and is very different, because it
shows what's happening under the hood and reveals that I redefined ::unknown
and I'm doing magic:
invalid command name "mytest"
while executing
"::_unknown mytest"
("uplevel" body line 1)
invoked from within
"uplevel 1 [list ::_unknown $args]"
(procedure "::unknown" line 2)
invoked from within
"mytest"
(in namespace eval "::request" script line 21)
invoked from within
"namespace eval request {
puts -nonewline ""
Is this the right behavior? It's expected? Maybe a bug or a still not
implemented
feature?
At the end, the practical side effect is that I loose the place where
the error happens,
because it's changed from the row where "mytest" is called, to the one
in ::unknown.
This could be a deal when the "mytest" name is dynamically built, so a
text search in
the code can't help in finding the error.
I don't know whether it could create other troubles.
are you sure you haven't a bug somewhere in the way you call the
::unknown error handler?
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
