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

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

Reply via email to