On 09/05/2011 12:27, Moritz Lenz wrote:
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.
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.
- David
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
