Re: catch replacing useful errorInfo

I use catch for the following reasons:

1. if a shared resource is used and released (like a file lock), an
error may abort release.

Hmm, that is about it, example:

proc ::datastore::restore { store } {

if {[exists $store]} {

set LockID [lock $store]
if {[catch {
set dataFile "[storeDirectory $store]/data"
# dataFile exists only if variables have been saved.
if {[file isfile $dataFile]} {
namespace eval ::datastore::store::$store [list source $dataFile]
} else {
namespace eval ::datastore::store::$store { }
}
set _RESULT 0
} err ]} {
unlock $store $LockID
closeStore $store
error $err "::datastore::restore failed"
}
unlock $store $LockID
closeStore $store
return
}

}

Notice that if caught, the unlock command is executed and store
closed, then the error is called again, with some additional
information. This can still be used by higher up procs if you decide
to catch.

It is important to remember a few things:

1. Catch makes it very difficult, or impossible, to track down
errors.
2. If the code within a catch does not compile, you get the previous
contents of errorInfo, which can lead you to think the error is
somewhere else.
3. Catch makes it more difficult to reuse code.
4. Catch is not an error reporting mechanism (again, catch destroys
error information).
5. Catch is not a program branching facility (like if).

Errors occur because of something not being done correctly prior to
the error, or because of the current state of the system. These are
exceptional conditions which are related to poor programming or bad
data. In any case, you need as much information as possible to
identify the cause. If you could identify the cause ahead of time, you
wouldn't need catch.

You could also use return -code return and return -code error in the
above code. These seem to be more consistent in application.

.

Relevant Pages

  • Re: catch replacing useful errorInfo
    ... if a shared resource is used and released (like a file lock), ... set LockID [lock $store] ...
    (comp.lang.tcl)
  • Re: Top tip for CTC run
    ... Always store and carry locks locked up so when you use them you must ... unlock them first thus proving you have the key and it works. ... so no chance of it happening again. ...
    (uk.rec.cycling)