where will we die to?
Yuval Kogman
a die will go to eventually, within a cascade of eval { }s and what
not.
In Perl 6 one thing that could ease this is to be able to easily
know where we will die to, without having to walk the stack and
checking which scope entries have a catch block.
The other thing is to be able to trace an exception: if we have 'die
"foo" but traced' then the exception should print "cought at ....
rethrowed" as it's doing that.
This second thing is much harder for me to pretend to implement
--
() Yuval Kogman <nothi...@woobling.org> 0xEBD27418 perl hacker &
/\ kung foo master: /me tips over a cow: neeyah!!!!!!!!!!!!!!!!!!!!!!
Larry Wall
: on the #catalyst channel today we had lots of pains debugging where
: a die will go to eventually, within a cascade of eval { }s and what
: not.
:
: In Perl 6 one thing that could ease this is to be able to easily
: know where we will die to, without having to walk the stack and
: checking which scope entries have a catch block.
How else would you implement it that doesn't impact performance?
One of the main reasons for having exceptions is that they're exceptional,
and should be pessimized with respect to ordinary code. Having to
write a stack introspection routine is not that big of a hardship.
: The other thing is to be able to trace an exception: if we have 'die
: "foo" but traced' then the exception should print "cought at ....
: rethrowed" as it's doing that.
: This second thing is much harder for me to pretend to implement
Maybe have the debugger .wrap all CATCH blocks?
Larry
Yuval Kogman
> On Thu, Mar 23, 2006 at 02:27:07PM +0200, Yuval Kogman wrote:
>
> How else would you implement it that doesn't impact performance?
> One of the main reasons for having exceptions is that they're exceptional,
> and should be pessimized with respect to ordinary code. Having to
> write a stack introspection routine is not that big of a hardship.
Oh, i mean without *manually* walking the stack - present some
standard library function like 'caller()' but only for catching
frames.
This is purely a usability issue...
Perhaps Perl 6 should ship with some "core" modules for development,
with this general stuff in place?
For example, a help() function, like Python has, things like
Devel::DumpVar, Benchmark, Test::WithoutModule, a profiler,
Devel::Loaded and other such introspection shortcuts,
Devel::SymDump, and even yours truely's Devel::Sub::Which (which
will just be a quick hack with the MOP introspection) and
Devel::STDERR::Indent ;-)
These tools should be useful for writing/hacking the compiler
toolchain itself - that is they should operate both within a
runtime, and if possible, on the intermediate representations as
well.
> Maybe have the debugger .wrap all CATCH blocks?
That sounds nice
--
Yuval Kogman <nothi...@woobling.org>
http://nothingmuch.woobling.org 0xEBD27418