#169 snit can destroy errorInfo in some cases

[Kirill Frolov]

Sometimes snit functions can be called from
exception processing code:

if {[catch {some_code }]} {
exception processing code
here snit called
...
}

It's possible in non evident way, for example,
then executed the following code:

proc procedure1 {...} {
set varname snit_object
trace add variable varname {snit_object destroy}
....
}

(this technique used in oomk -- http://www.equi4.com\)

When error occurs in procedure1, trace code will be
called, which invokes snit destructor. But SNIT CAN
DESTROY ::errorInfo and ::errorCode GLOBAL VARIABLES
in many cases. As for example, when snit calls any
method, including destructor. And you get obscure
error message. Because snit's code abound with
constructions like following:

if {[catch {set snit_var} result]} {
blablabla...
}

Here, if snit_var is not defined, errorInfo will be
corrupted with message like
"Snit_typemethodCache($mehod) -- no such variable"...

This patch *partially* corrects described problems.
("catch" not used there possible or ::errorInfo and
::errorCode there possible preserved).
In some cases, then real error occurs in snit, there
are no solution where old value of errorInfo can be
stored. This is not snit bug, but tcl defect, as I
think. :-(

[Kirill Frolov]

patch for snit 1.1 (fixes corruption of ::errorInfo and ::errorCode by snit)