Subject | Re: [Firebird-Architect] Another plea for clearer error messages... |
---|---|
Author | Ann W. Harrison |
Post date | 2004-10-27T16:30:03Z |
At 06:47 AM 10/27/2004, Jonathan Neve wrote:
manage error messages and add them easily. Now the tools are
obsolete so adding an error message is hard.
A second problem is that when Borland integrated the various
utilities into the services API and merged their error returns,
the numbering of message exceeded the ability of, well, me, for
example, to manage mentally. So I need the tools.
A third problem is that the easy way to add an error message - use
isc_$random and a text string - is a horrible violation of any standard
of internationalization. We've got this message facility designed for
translation - hard coding messages is a serious step backward.
If we make it easier to add messages, the resistance to fixing ambiguous
messages will go done. For now, it's just so much easier to use an
imprecise but reasonably appropriate message that we can't fix the problem.
Regards,
Ann
>A while ago, I mentionned the issue of error messages, and suggestedThe first problem here is that once upon a time there was a way to
>making them a bit clearer and more helpful, in particular, by providing
>(in as many cases as applicable), the table/column name, the value of
>column/parameter, the line number (in triggers/procedures), as well as
>just more precision for certain highly ambiguous error messages such as
>"Column unknown", "Arithmetic overflow or string truncation", or
>"Unknown datatype", etc.
manage error messages and add them easily. Now the tools are
obsolete so adding an error message is hard.
A second problem is that when Borland integrated the various
utilities into the services API and merged their error returns,
the numbering of message exceeded the ability of, well, me, for
example, to manage mentally. So I need the tools.
A third problem is that the easy way to add an error message - use
isc_$random and a text string - is a horrible violation of any standard
of internationalization. We've got this message facility designed for
translation - hard coding messages is a serious step backward.
If we make it easier to add messages, the resistance to fixing ambiguous
messages will go done. For now, it's just so much easier to use an
imprecise but reasonably appropriate message that we can't fix the problem.
Regards,
Ann