Front page | perl.perl6.users |
Postings from September 2011
Re: More bugs or PEBKAC
Thread Previous
|
Thread Next
From:
Moritz Lenz
Date:
September 5, 2011 12:27
Subject:
Re: More bugs or PEBKAC
Message ID:
4E6522AE.9090508@faui2k3.org
On 09/05/2011 09:03 PM, Carl Mäsak wrote:
> 1parrota (>):
>> 1. Should there be a way to make "die" behave like the Perl 5 version,
>> reporting the place of death unless the message is terminated by \n ?
>> The \n no longer suppresses the location indormation. I can't find a
>> definition either way in the Synopses.
>
> Yes, there should.
>
> The problem is one of the perfect being the enemy of the good. People
> pretty much agree that the mechanism shouldn't be governed by "\n" at
> the end of the error string, but no-one has suggested anything
> significantly more attractive either. So here we are, currently
> without a way to get "die" (and "warn") without location information.
FWIW the current factoring allows the catcher of the exception to
control whether a backtrace is printed. A solution is thus to catch
exceptions on the outermost level of your program, and print the
exception (but not the backtrace) there.
A cheap (but probably wrong) approach would simply be a named argument
to &die, like
die 'OH NOEZ', :suppress-backtrace
But as Larry usually points out, such a modified behavior is often a
sign of design smell.
And I guess that's what happens here: we conflate two concepts here:
Error messages that usually stem from errors that the programmer made,
and error messages for things that the user did wrong (and which I guess
is the reason one wants to surpress backtraces -- are there others?)
So I guess the exception object could contain a hint whether the error
is a user error or a programming error. All those errors that are thrown
by the Perl 6 compiler count as programming error, but we can still
provide a X::UserError class, which disables printing of backtraces by
default.
The question is if we provide a separate sub for such cases (error() or
report-error() or so), or if we rely on something like
UserError.new(message => 'You did something wrong here').throw
or something similar.
Cheers,
Moritz
Thread Previous
|
Thread Next