handling of errors in slave
- From: wjposer@xxxxxxxxxxxxxxxxxxx (William J Poser)
- Date: Sun, 21 Aug 2005 17:06:03 +0000 (UTC)
I have a question concerning the handling of errors in slave interpreters
used to read files created by ordinary users, such as init files.
I'm assuming that the init file is read via something like this:
proc ReadInitFile {name} {
if { [catch {interp invoke init source $name} msg] } {
ShowMessage [format [_ "Error on reading init file %1\$s: %2\$s"] $name $msg]
} else {
ShowMessage [format [_ "Executed init file %s"] $name]
}
interp delete init
}
If the user types "ValloonHelpShowP" instead of "BalloonHelpShowP",
the resulting error message is:
Error on reading init file .msgrc: invalid command name "ValloonHelpShowP"
The incorrect command name is caught by the slave interpreter and reported
using the name the user typed, which is a small deviation from the name by
which the command is known to the user and listed in the documentation.
But if the user types "BalloonHelpShowP 0 n", the error message is:
Error on reading init file .msgrc: wrong # args: should be "SetBalloonHelpShow b"
In this case the error is caught by the master, not the slave, and reported
using the name that the command has in the master. This may be confusing to the
user. In this case, as in other cases in which the differences between internal
and external names are motivated by different namespace organization and similar
considerations, the two names may be similar enough that the user will realize
which command is causing the problem, but suppose that the internal and external
names are different because they are in different languages? Suppose that
a monolingual francophone user receives this error message:
Erreur en lisant le scripte d'initialisation .msgrc:
wrong # args: should be "SetBalloonHelpShow b"
(I just checked and the part of the message that comes from tcl comes out in
English even though I have set my locale to fr_FR. In principle of course
this part might come out in French.)
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.
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.
--
Bill Poser, Linguistics, University of Pennsylvania
http://www.ling.upenn.edu/~wjposer/ billposer@xxxxxxxxxxxx
.
- Follow-Ups:
- Re: handling of errors in slave
- From: Jeff Hobbs
- Re: handling of errors in slave
- Prev by Date: Re: tackling the packer
- Next by Date: Re: What is the procedure for creating a starkit base for 8.4.11?
- Previous by thread: trying to understand TclUDP
- Next by thread: Re: handling of errors in slave
- Index(es):
Relevant Pages
|
|
