Hi all. I'm writing an error handling proc. I've redefined bgerror, but, I'd also like to collect any errors generated by [return -code error] and have them handled by this proc too. (At the moment, they're either displayed in a simple dialog on Windows or to the console.) How would I achieve this?

Pavel Novozhilov <pnovozhilov@gmail.com> wrote: > On Nov 18, 3:27 pm, Synic <flavp+hfr...@nhgbaf.arg.nh> wrote: >> Hi all. >> >> I'm writing an error handling proc. I've redefined bgerror, but, I'd also >> like to collect any errors generated by [return -code error] and have >> them handled by this proc too. (At the moment, they're either displayed >> in a simple dialog on Windows or to the console.) >> >> How would I achieve this? > > Take a look at this thread: > > http://groups.google.com/group/comp.lang.tcl/browse_frm/thread/b59fb7f4139853b5/8641733f2caaef77 > > That might be useful to you. > Pavel. It's an interesting thread, but, it's more about sending the return code. What I'm really hoping for is the name/s of the functions or procs used to output those errors to the user. I know you can redefine some internal commands like [return] itself (obviously not a wise move, but, it's possible). With a bit of luck, I'd like to redefine whatever is responsible for the error output instead: so it uses my output method rather than the default one. Cheers for the pointer though.

Pavel Novozhilov <pnovozhilov@gmail.com> wrote: > On Nov 19, 1:36 pm, Synic <flavp+hfr...@nhgbaf.arg.nh> wrote: [...] >> It's an interesting thread, but, it's more about sending the return >> code. What I'm really hoping for is the name/s of the functions or >> procs used to output those errors to the user. >> >> I know you can redefine some internal commands like [return] itself >> (obviously not a wise move, but, it's possible). With a bit of luck, >> I'd like to redefine whatever is responsible for the error output >> instead: so it uses my output method rather than the default one. >> >> Cheers for the pointer though. > > If I understand you correctly you want to know the name of the > procedure that called the error handler procedure. You can do that > with use of info command. Nah. I'm not after that. As an example, what I want is to is replace the dialog on Windows (and the puts on x11) which outputs the string: invalid command name "random::garbage" When fed the command: % random::garbage blah The string "invalid command random::garbage" originates from a call of [return -code error] from Tcl code somewhere. (bgerror doesn't handle error output from that type of error at all.) I don't want the default error dialog/puts code used for displaying that sort of error to be used; I want to use a proc of my own instead. I'm hoping that whatever proc or function it is which generates that dialog box on Windows to display [return -code error] errors is something which can be redefined.

Donald G Porter <dgp@nist.gov> wrote: > Synic wrote: >> I'm writing an error handling proc. I've redefined bgerror, but, I'd also >> like to collect any errors generated by [return -code error] and have >> them handled by this proc too. (At the moment, they're either displayed >> in a simple dialog on Windows or to the console.) >> >> How would I achieve this? > > I don't understand the question. > > Maybe you are looking for the new [interp bgerror] feature of Tcl 8.5 ? Hi Don. I'm not sure, but, I wouldn't think so. $ /usr/local/ActiveTcl-8.5/bin/wish8.5 % proc bgerror {arg} { puts "***ERROR: $arg" } % random::garbage blah invalid command name "random::garbage" What I'm after is the name of whatever is handling the output of the error string "invalid command name "random::garbage"" -- in the hope I can use my own proc to deal with the error message instead. [return -code error] seems to be what is generating those errors not caught and sent for output by bgerror. I'm after the bgerror equivalent for [return -code error] type errors, if there is one.

My news server's upstream seems to have stopped feeding articles through for the moment, but, I see from Google some responses. Thanks to Alexandre Ferrieux for the info regarding the code handling [return -code error]. It's bad news, but, much better to know for sure than die wondering. If my C skills were other than deplorably rusty, I'd offer a patch to check for the presence of a defined proc to handle this sort of output task and only fall back to direct output if there's nothing otherwise defined. But my C skills are, and there may be good reasons why this would be silly idea anyway :). At this stage, it looks like the advice to wrap the whole script around a catch is looking the most viable. I was hoping to avoid that as it's also the most ugly too. Pavel Novozhilov asked Bryan Oakley whether chucking a catch around the entire script was wise as "I tried it once and found troubleshooting to be very difficult because wherever my program crashed there was no debugging information printed. Script would just exit unless I make a code to print the errors." For my purposes, this is how the catch will be implimented: package require tcltalkback ::tcltalkback::setup ?options? if {[catch { ######################### The rest of your Tcl script goes here ######################### } ]} { bgerror "Internal script error:" } Rather than catching errors to ignore them, the errors (of whatever type) cause a bgerror proc to be called. The first two lines above would be commented out during development, so errors get sent to the standard bgerror proc we know and love, but reenabled when the application is packaged up and sent to the user. The user gets a nice friendly dialog instead. Thanks to everyone for putting up with my silly questions in this thread. And for the info too :). ---- PS: I posted the above a little while back but it seems the upstream's outgoing connection is borked too. Apologies if this ends up being posted twice if/when their connection returns.