Front page | perl.perl5.porters |
Postings from July 2013
On 26 July 2013 01:49, David Golden <xdg@xdg.me> wrote:
> I think what David is getting at is that we don't have to solve
> everything at once.
Right. After all, even lightning gives the illusion of exploring many
possible paths to ground prior to finding the eventual path of least
resistance.
> That's almost intentionally pathological, though. And the failure of
> existing stacktrace tools on exception objects is an existing problem
> in those modules irrespective of a change in core.
Indeed, however, I figure being able to get back traces out of things
is reasonably important, so whatever we do, that should be one of the
things we (at least eventaully) solve.
> Like what? caller() and constructing a proper message that matches the form?
My memory is that this is somewhat a problem, because this means you
have to walk the whole stack and take a snapshot of the stack,
iterating calls to caller(), for which the respectful code in even
Carp.pm is a rather nasty rabbit warren.
And my memory of seeing this in Object implementations is that
creating a stack array is a little bit expensive if the exception is
just going to be flow control, and the stack trace will never be
needed.
Thats the real perk of Carp::Always and Devel::SimpleTrace, you don't
have to pay for that if you're not using it.
Now, if there could be some lazy way to reference a point in Perl
time/code/memory at the time an exception was thrown, that made it
possible to introspect the stack that occurred at that time, in an
efficient manner, that'd be cool.
I'd be especially cool, because it wouldn't inherently bind you to
having one type of stack trace presentation, and one type of stack
trace presentation only, things like Carp::Always could hook in to
this facility, ie:
if ( $_->isa('exceptionything') ) {
my $stack = CORE::stacktracefor($_);
print $_->message . custom_stacktrace_formatter($stack);
}
( The point being its useful to be able to decouple the presentation
logic from the actual exception implementation so that presentation
can be changed at the top level when needed )
--
Kent
Thread Previous
|
Thread Next