Re: handling of errors in slave
- From: Jeff Hobbs <jeffh@xxxxxxxxxxxxxxx>
- Date: Sun, 21 Aug 2005 22:16:00 -0700
William J Poser wrote:
Our French speaker is likely to have no idea that "SetBalloonHelpShow" is the internal name for the command "ActiverInfobulles" in his or her init file.
My gut feeling is that it's not a great idea to make the controller language go so native, but that doesn't really address your problem ...
Has anyone addressed this problem? Offhand, the only way I can see to deal with it is to trap the error messages, parse out the command names, translate them into the user's language (which by hypothesis we can already do since it must have been done creating the slave alias in the first place), and reassemble the error message before showing it to the user. I haven't actually tried to do this yet, but it presumably wouldn't be terribly difficult since the form of the error messages is limited and we can generate a list of commands to search for. However, the task would be simplified if Tcl supported this by setting a variable to contain the name of the offending command so that we don't have to parse it out.
Well, you can see what $::errorInfo holds. I have had similar situations where we did parse the error result (in fact, I think the core Tcl does it in some code). You can actually see tkcon do this for another purpose - the hot errors functionality (when you pop up an error, it will hotlink the function names so you can see/edit the code).
-- Jeff Hobbs, The Tcl Guy http://www.ActiveState.com/, a division of Sophos .
- References:
- handling of errors in slave
- From: William J Poser
- handling of errors in slave
- Prev by Date: Re: tackling the packer
- Next by Date: Re: tackling the packer
- Previous by thread: handling of errors in slave
- Next by thread: tile installation failture
- Index(es):
Relevant Pages
|
