where will we die to?
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.
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 [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me tips over a cow: neeyah!!
pgpv0ddyWDvMt.pgp
Description: PGP signature
Re: where will we die to?
On Thu, Mar 23, 2006 at 02:27:07PM +0200, Yuval Kogman wrote:
: 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
Re: where will we die to?
On Thu, Mar 23, 2006 at 08:14:03 -0800, Larry Wall wrote: 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 [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpb1i4cgMp0u.pgp Description: PGP signature
