Re: try... query

On 06/12/2024 17:59, Ralf Fassel wrote:

* Alan Grunwald <nospam.nurdglaw@gmail.com>
| proc allocateResources {} {
|     set obj1 [Some_mechanism]
|     try {
|         set obj2 [Some_other_mechanism]
|         try {
|             do_various_other_stuff
|         } on error {message errorDict} {
|             $obj2 destroy
|             return                                          \
|                 -code error                                 \
|                 -errorcode [dict get $errorDict -errorcode] \
|                 -errorinfo [dict get $errorDict -errorinfo] \
|                 $message
|         }
 As Harald pointed out, 'finally' is the way to go here (even if the
"if exist" is clunky :-).
 I just wanted to point out that you could use the errorDict directly, as in
    try {
     ...
   } on error {msg opts} {
     ...
     return -options $opts $msg
   }
 instead of extracting errorinfo and errorcode manually, and if I use
that form, I get the expected behaviour:
      proc foo {} {
         try {
             puts "level 1"
             try {
                 puts "level 2"
                 error "err level 2"
             } on error {msg opts} {
                 puts "error in level 2"
                 return -options $opts $msg
             }
         } on error {msg opts} {
             puts "error in level 1"
             return -options $opts $msg
         }
     }
          % catch foo
     level 1
     level 2
     error in level 2
     error in level 1
     1
          % set errorInfo
     err level 2
         while executing
     "error "err level 2""
         (procedure "foo" line 6)
         invoked from within
     "foo"
 HTH
R'

Thanks Ralf,
As I pointed out to Harald, deleting the objects in a finally clause is explicitly not what I want to do since I wish to return them if there are no errors. I believe that I need to propagate the error explicitly if I add an on error clause. I'll see what happens if I do return -options $errorDict $message rather than extracting and specifying -code, -errorcode and -errorinfo. I guess if would help if I could recall what issue emerged when I tried doing it that way in the past, but sadly...
Alan