develooper Front page | perl.perl5.porters | Postings from June 2008

Re: Fatal/autodie exception hierarchies for Perl 5

Thread Previous | Thread Next
Paul Fenwick
June 3, 2008 04:42
Re: Fatal/autodie exception hierarchies for Perl 5
Message ID:
G'day Larry / p6l / p5p,

Larry Wall wrote:

> One little problem at the outset here is that Perl 6 has almost no
> concept of "built-in" or "CORE", except insofar as the Prelude happens
> to choose to import certain subs into the user's scope by default.
> Once you actually start parsing and calling functions, there is
> no distinction at all between different versions of "open", say.

I think that chromatic's suggestion of roles is an excellent one.  In P5 we 
certainly do have a concept of built-in (core) functions, and if nothing 
else autodie uses this internally to work its dark magicks.

In P6, I imagine we can just drop the the core and user roles, leaving the 
other roles intact.

Originally, my plan was for the vanilla autodie:

	use autodie;

to enable autodie for all core functions in scope.  However I think that 
having a 'default' role makes quite a lot of sense.  User-defined 
subroutines can register themselves with the default role, so a vanilla 
autodie can enable Klingon semantics[1] for whatever system is being used at 
the time.

>> Currently, when testing exceptions from autodie, we can use:
>> 	given ($@) {
>> 		when (undef)   { say "No errors here" }
>> 		when ('open')  { say "Open died" }
>> 		when (':file') { say "Some sort of file error" }
 >>              ...
>> 	}
> That may be what we have to do for Perl 5, but from the Perl 6
> viewpoint it's duplicating information that should derive directly from
> the type and introspection systems.

For the following discussion, I fear I'm bumping my head on the low ceiling 
of my P6 knowledge, so I apologise in advance for my ignorance.

The autodie exceptions are real objects, which do contain an awful lot of 
information about what went wrong, including the failed subroutine, where it 
was called from, what arguments were involved, and so on.  They just happen 
to smart-match against our roles, since those are things that are likely to 
be commonly checked.

However I suspect this is a very different system to what's intended for P6 
given the next paragraph:

 > For instance, functions are real objects in P6,
 > and can have other methods than just the "invoke" method.  If you want
 > to tell a function how to behave, you might just talk to it directly...

So could I theoretically say (in pidgin P6):


That certainly has a lot of value when thinking about parallel processing, 
since errors can be handled in-situ, ignored, or handled later when the data 
is collated or used.

However there's still a number of quite concrete current-day examples where 
the traditional try/catch paradigm provides excellent value.  The classic is 
a single-threaded sysadmin task:

	try {
	catch {
	finally {

Here if any part of our try fails, then we immediately want to stop what 
we're doing, rather than overwriting the wrong tape, or deleting files we 
didn't successfully back-up.  I trust these sorts of exceptions will still 
be around in P6?

> That's because it would be S33, which hasn't been written yet... :)

Oh good, my searching skills aren't completely dead then.


> As chromatic suggested, it would be good to use some kind of role-ish
> mixin idea (with or without Moose) instead of hierarchies of strings.

Given my ignorance of Moose, and my desire for autodie to be a candidate for 
inclusion in the P5 core, I was intending autodie to be orthogonal to Moose. 
  Of course I'm happy for there to be hooks which Moose may find useful.

I do very much like the idea of roles, they're going to be quite useful. 
Mixins I haven't even considered.  I'll make sure there's a sane way to use 
them, but the ones provided with standard autodie will probably be quite 

> I dunno--you're dragging us back down from the stratosphere of theory
> to the troposphere of practice.
> I don't expect we can keep things entirely lined up, but it would
> be nice to avoid gratuitous divergence if we can.

I'm not sure actually sure if we've avoided divergence yet, but unless 
there's any barotrauma due to the sudden change in pressure, I'll continue 
to throw autodie exception-related plans to p6l as they happen.  ;)

All the best,


[1] Klingon semantics: It is better to die() in the attempt than to return() 
in failure.  I'll buy a beverage for whomever can help me translate that 
back into Klingon in time for OSCON. ;)

Paul Fenwick <> |
Director of Training                   | Ph:  +61 3 9354 6001
Perl Training Australia                | Fax: +61 3 9354 2681

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About