Re: try... query

On 06/12/2024 20:12, Alan Grunwald wrote:

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

* Alan Grunwald <nospam.nurdglaw@gmail.com>

<all helpful context removed>

 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...
 

Thank you very much indeed. Modifying my genuine code to use
      return -options $errorDict $message
makes everything work as I originally expected - the resources are tidied away correctly, and the error is propagated properly.
I'm now a happy bunny, but am slightly troubled by wondering why my original attempt didn't work. I've had a closer look at the try manpage and see the statement
"If an exception (i.e. any non-ok result) occurs during the evaluation of either the handler or the finally clause, the original exception's status dictionary will be added to the new exception's status dictionary under the -during key."
which I had previously overlooked. I guess that no -during key is included if I raise the error using -options, but I'm not convinced that there's anything on the try manpage that should make me expect that no on error handler will be executed if there's a -during key. Granted this is kind of weird stuff that I wouldn't expect to get right first (or second or third) time, but I would hope to understand what's going on by the time I have got it right!
Anyway, thanks again, further explanations would be welcome, but are by no means essential :-)
Alan