Parrot error messages
Jonathan "Duke" Leto
jonathan at leto.net
Mon Aug 15 17:38:19 UTC 2011
On Sun, Aug 14, 2011 at 6:13 PM, Andrew Whitworth <wknight8111 at gmail.com> wrote:
> How tied are we to the exact format and wording of the error messages
> and exception backtraces produced by our current parrot executable?
Not so tied that we don't want to improve them.
> I'm working on a new frontend in the whiteknight/frontend_parrot2
> branch, and it's going to be extremely difficult to exactly reproduce
> some of these error messages verbatim. The only thing that is going to
> be changed are the error messages when you run parrot from the parrot
> binary, not error messages printed out by anything running on Parrot
> or programs compiled with pbc_to_exe.
Can you give some specific examples?
> We have several tests which use perl5 regular expressions to match
> error messages in whole or in part. How valid or important are these
Throwing exceptions/errors as strings is wrong by design and checking them via
regexen is wrong by design as well, but we have them because they were better
> Would the text and information content of error messages be covered by the
> deprecation policy?
Somewhat, but I don't think that should be a barrier to improving them and
making them actually useful.
> Assuming things can be changed, are there any requests?
We should be throwing exception objects, which contain metadata and have a
standardized string representation. That way, tests can inspect the actual
error object and not be closely tied to changing string representations. Also,
this allows for the internationalization of error messages and makes testing
Thanks for asking these important questions.
> --Andrew Whitworth
Jonathan "Duke" Leto <jonathan at leto.net>
Leto Labs LLC
209.691.DUKE // http://labs.leto.net
NOTE: Personal email is only checked twice a day at 10am/2pm PST,
please call/text for time-sensitive matters.
More information about the parrot-dev