Re: Fatal/autodie exception hierarchies for Perl 5
G'day Josh / p5p / p6l,
given ($@) {
# [snip]
default{ say "Not an autodie exception." }
}
If you're going to write that into some documentation, I wish you'd
make default say that it's exception suicide.
The documentation clearly needs to make clear what that default means,
because it's certainly not exception suicide. The exceptions thrown from
autodie bind smart-match (used in given/when) to a 'does/has_role' style
check. The ':all' test (which may change its name) checks against a
meta-role shared by all autodie exceptions. If something doesn't match
that, then it wasn't an exception from autodie. It could have been an
exception from something else, or even a plain string exception.
Semi-recently at work I found that a few buggy exception objects in
the global $@ were clearing themselves out of $@ as a side effect of
examining them for truth. It's quite annoying and mysterious when it
happens.
Yes, I've seen this sort of behaviour too, and I'm being particularly
mindful to make sure it doesn't happen with the code in autodie. I've
marked myself down a TODO item to make sure there's a big barrage of tests
to ensure that $@ still contains what we expect at the end of each exception
handling block.
Cheerio,
Paul
--
Paul Fenwick <[EMAIL PROTECTED]> | http://perltraining.com.au/
Director of Training | Ph: +61 3 9354 6001
Perl Training Australia| Fax: +61 3 9354 2681
Re: Fatal/autodie exception hierarchies for Perl 5
On Sun, Jun 1, 2008 at 7:31 PM, Paul Fenwick <[EMAIL PROTECTED]> wrote:
> 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" }
>when (':io') { say "Some other error" }
>when (':CORE') { say "Some other CORE error" }
>when (':USER') { say "A non-CORE error" }
>when (':all') { say "Any autodie exception at all." }
>default{ say "Not an autodie exception." }
>}
If you're going to write that into some documentation, I wish you'd
make default say that it's exception suicide.
given( my $_ = $@ ) {
...
default { say '$@ committed suicide' }
}
Semi-recently at work I found that a few buggy exception objects in
the global $@ were clearing themselves out of $@ as a side effect of
examining them for truth. It's quite annoying and mysterious when it
happens.
Josh
Re: Fatal/autodie exception hierarchies for Perl 5
Larry Wall wrote: On Wed, Jun 04, 2008 at 10:42:33AM -0400, Mark J. Reed wrote: : However, I think we are now officially *way* off topic for Perl6... Not really--a Klingon army is a *parallel* processor, and just because one Klingon dies doesn't mean the whole army should suddenly die too. Traditional exception handling is more like equipping each Klingon with a dead-man's switch attached to a nuke. Dying by accident in someone else's nuke blast would be a death without honor. So the point of the Perl 6 exception model is to try to keep as many warriors alive as long as possible in order to inflict the maximum possible damage on the enemy, which is our highest goal, after all. :) And let us not forget that, when the unthrown exception returns, one can then choose to do the honorable thing...
Re: Fatal/autodie exception hierarchies for Perl 5
Mark J. Reed schrieb: I think the simplest and most Klingonlike expression of the sentiment is simply this: yIQap pagh yIHegh! (Succeed or die!) But you could say something like: SuvwI' yIDa: yIHegh! bIlujchugh yIcheghQo'! (Behave as a warrior: die! If you fail, do not return!) Thanks for setting that straight. And yes, I concurr, I must have misread the old scrolls... ;-) However, I think we are now officially *way* off topic for Perl6... Are we? Isn't this the thread about porting Lingua::tlhIngan to perl6? :-)
Re: Fatal/autodie exception hierarchies for Perl 5
On Wed, Jun 4, 2008 at 7:21 AM, Mark J. Reed <[EMAIL PROTECTED]> wrote: > The catch block is lexically contained within the try block, so the > inviolate nature of the curlies remains intact. thank you.
Re: Fatal/autodie exception hierarchies for Perl 5
On Wed, Jun 04, 2008 at 10:42:33AM -0400, Mark J. Reed wrote: : However, I think we are now officially *way* off topic for Perl6... Not really--a Klingon army is a *parallel* processor, and just because one Klingon dies doesn't mean the whole army should suddenly die too. Traditional exception handling is more like equipping each Klingon with a dead-man's switch attached to a nuke. Dying by accident in someone else's nuke blast would be a death without honor. So the point of the Perl 6 exception model is to try to keep as many warriors alive as long as possible in order to inflict the maximum possible damage on the enemy, which is our highest goal, after all. :) Larry
Re: Fatal/autodie exception hierarchies for Perl 5
On Wed, Jun 4, 2008 at 9:09 AM, Roland Giersig <[EMAIL PROTECTED]> wrote:
> batlh yiHegh SuvwI'mo! yIcheghbe' lujwI'mo'!
> Die honorably as a warrior! Do not return as a looser!
Not quite. mo' means "because of the ", so the above says
something like 'die because of the warrior', 'return because of the
loser'. Also, {-be'} is for negating statements, not imperatives; you
want {-Qo'} to convey "don't".
I think the simplest and most Klingonlike expression of the sentiment
is simply this: yIQap pagh yIHegh! (Succeed or die!)
But you could say something like: SuvwI' yIDa: yIHegh! bIlujchugh yIcheghQo'!
(Behave as a warrior: die! If you fail, do not return!)
However, I think we are now officially *way* off topic for Perl6...
--
Mark J. Reed <[EMAIL PROTECTED]>
Re: Fatal/autodie exception hierarchies for Perl 5
Paul Fenwick wrote: [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. ;) The concept of "better ... than" is difficult to express and not very warrior-like. I would suggest using the ancient ritual words that leaders have used for eons to send their soldiers into battle: batlh yiHegh SuvwI'mo! yIcheghbe' lujwI'mo'! Die honorably as a warrior! Do not return as a looser! Qapla'! rol'a'
Re: Fatal/autodie exception hierarchies for Perl 5
The catch block is lexically contained within the try block, so the inviolate nature of the curlies remains intact. On 6/3/08, David Nicol <[EMAIL PROTECTED]> wrote: > On Mon, Jun 2, 2008 at 6:50 PM, Larry Wall <[EMAIL PROTECTED]> wrote: > >>* Exception handlers run in the lexical context of the block being >>tried. >>* Exception handlers run in the dynamic context of the code that is >>failing. > > the first seems dangerous, esp. considering the availability of the > second. Has "lexical" been redefined? > -- Sent from Gmail for mobile | mobile.google.com Mark J. Reed <[EMAIL PROTECTED]>
Re: Fatal/autodie exception hierarchies for Perl 5
On Mon, Jun 2, 2008 at 6:50 PM, Larry Wall <[EMAIL PROTECTED]> wrote: >* Exception handlers run in the lexical context of the block being >tried. >* Exception handlers run in the dynamic context of the code that is >failing. the first seems dangerous, esp. considering the availability of the second. Has "lexical" been redefined?
Re: Fatal/autodie exception hierarchies for Perl 5
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):
open.on_fail(try_the_other_drive);
print.on_fail(panic);
system.on_fail(wake_sysadmin_from_slumber);
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 {
mount_tapes;
check_tape_labels;
backup_files;
delete_old_files;
}
catch {
wake_sysadmin_from_slumber;
}
finally {
unmount_tapes;
}
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.
[snips]
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
lightweight.
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,
Paul
[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 <[EMAIL PROTECTED]> | http://perltraining.com.au/
Director of Training | Ph: +61 3 9354 6001
Perl Training Australia| Fax: +61 3 9354 2681
Re: Fatal/autodie exception hierarchies for Perl 5
G'day chromatic / p5p / p6l, Make a list of all possible types of exceptions, define them as roles, and group them that way. Any given exception can implement multiple roles (:CORE and :io, for example, or a specialization of that role that also does :USER). Excellent point. I've been largely ignoring the user exceptions, and that they may wish to declare themselves as having an :io, :math, or similar role. So, roles are in, I'll need to provide an appropriate interface for user code to make use of them. Larry's post I'll be digesting on my trip home tonight. ;) Cheerio, Paul -- Paul Fenwick <[EMAIL PROTECTED]> | http://perltraining.com.au/ Director of Training | Ph: +61 3 9354 6001 Perl Training Australia| Fax: +61 3 9354 2681
Re: Fatal/autodie exception hierarchies for Perl 5
On Mon, Jun 02, 2008 at 12:31:34PM +1000, Paul Fenwick wrote:
> G'day p6l and p5p,
>
> I'm currently working on the 'autodie' pragma for Perl 5, which is
> essentially 'Fatal' but with lexical scope. It's similar to the 'fatal'
> pragma described in S04/Exceptions.
>
> autodie is implementing an exception hierarchy for in-built functions.
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.
As chromatic points out in his inimitable style, a hierarchical
classification often forces the user to make meaningless choices in
such a case.
It's much like in the old days when configuration scripts switched
from being OS-based to feature-based, because you never knew which
OS's were going to implement which features when...
> Essentially we have a tree that looks like:
>
> :all
> :USER
> :CORE
> :math
> atan2
> :io
> :file
> open
> close
> :filesys
> opendir
> :socket
> accept
> bind
> connect
> ...
>
> 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" }
> when (':io') { say "Some other error" }
> when (':CORE') { say "Some other CORE error" }
> when (':USER') { say "A non-CORE error" }
> when (':all') { say "Any autodie exception at all." }
> default{ say "Not an autodie exception." }
> }
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. P5 tends to force you to represent
a lot of information as strings that is more naturally represented by
the metamodel in P6. 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...
> There's a 5 minute presentation on what autodie is and how it currently
> works at:
>
> http://pjf.id.au/blog/?position=540
>
> This also looks very similar to what I remember is the desired plan for P6
> exception handling, although my memory may be playing tricks on me as I
> can't seem to find the document where I read this.
That's because it would be S33, which hasn't been written yet... :)
> So, why does p6l care? Well, if there's already a p6 exception hierarchy
> designed for built-ins, I'd like to use it. It saves me work, and saves
> surprises for the developers. If there isn't a p6 exception hierarchy yet,
> then I'd like for p6 to have the option of stealing mine, for essentially
> the same reasons.
We could use someone of a practical turn of mind to write S33 for us.
But it does need to fit into P6-Think, and P6's exception-handling
model is rather different from P5's. To wit:
* All exception variables are unified into the $! variable.
* $! is now lexical (but dynamically visible to subcalls).
* As with autodie, fatality is lexically scoped, but that's because
the dynamic scope asks the outer lexical scope what it wants to do
when you call fail().
* Instead of return bare "undef", failing functions generally
return "unthrown exceptions" that keep all the info that
would have been in a thrown exception.
* The default is still not to throw an exception, but any unhandled
exceptions are eventually reported as if they had been thrown
immediately.
* Throwing an exception does not automatically unwind the stack
one of the handlers asks for that.
* Warnings are just exceptions that print their message and then
"forget" to unwind the stack.
* Exception handlers run in the lexical context of the block being
tried.
* Exception handlers run in the dynamic context of the code that is
failing.
This is mostly discussed in S04.
I do think that one practical difference will be that people aren't
going to be terribly interested in enumerating which functions pay
attention to the current exception policy, since the new default
policy will hopefully be a bit saner than P5 can manage, and the
it will likely be possible to apply policy changes more consistently
when policy changes are needed because the language is designed
to be mutable.
There is also going to be somewhat less cultural pressure toward
a throw-by-default model in program
Re: Fatal/autodie exception hierarchies for Perl 5
On Sunday 01 June 2008 19:31:34 Paul Fenwick wrote: > Questions I'm seeking answers to are: > > * Is there a document that describes the current p6l exception hierarchy? > My searching skills seem to be impaired today. > > * Does anyone have any input they'd like to make before I start fleshing > out the hierarchy for p5 autodie? Hierarchies suck, especially singly-rooted hierarchies. Then again, multiply-rooted hierarchies turn into big cyclic graphs. Make a list of all possible types of exceptions, define them as roles, and group them that way. Any given exception can implement multiple roles (:CORE and :io, for example, or a specialization of that role that also does :USER). -- c
