On 09/05/2011 12:27, Moritz Lenz wrote:
From what you say, I'd hope for something like trace() (or backtrace())
vs. err() vs. warn(), to continue using verbs while keeping the concepts
clear. I don't think the hint should be with the error object itself.
Perhaps die() is too ingrained to die.
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
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
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.
P.S. I haven't been following IRC as much as I used to, so my apologies
if something similar has already been suggested there.
David Romano .:. un...@cpan.org