On Wed, Sep 03, 2008 at 06:41:10PM -0500, John M. Dlugosz wrote:
> Larry Wall larry-at-wall.org |Perl 6| wrote:
>> a() orelse b()
>>
>> you might want to:
>> succeed on a()
>> trap mild failure of a() and try to succeed on b() instead
>> fail completely on drastic failure of a()
>>
>> At the moment this three-way distinction depends on whether a() returns
>> defined/undefined or throws an exception. Maybe that's good enough.
>> I don't want to overcomplexify things, but I don't want to
>> undercomplexify them either. :)
>>
> I'm thinking that, rather than have a zillion options to pre-configure
> the fail mode of that group of functions, it can be done by having a
> CATCH handler that calls resume on the ones you want to pop back out.
>
> { # some block scope
> use fail;
> a() orelse b();
> more-stuff-here;
> CATCH {
> when xxx { .resume() }
> }
I think ".resume" is not quite right, since resume would tell the fail
to return back into the body of a() as if it were merely a warning.
(Which is how we do warnings, after all.) We need a name for what fail
does when "fatal" isn't turned on, which might simply be a .return(),
though that's going to be confusing to people who think it returns
from the outer routine rather than from a(). So maybe we should give
it an obscure name like .interesting() or some such to turn a thrown
exception into a mere interesting value of undef.
Presumably a failure that is returned rather than thrown is already
considered interesting. :)
I suppose some will be inclined to turn on "use fatal" and defatalize
everything with .interesting, though I'm pretty certain that would
not be nearly as efficient as if fail just returned directly.
Another potential issue is that CATCH doesn't distinguish exceptions
coming from the current block from those coming from the subcall to a().
So it could end up returning Failure from the current block when
you intended to force return of Failure from a(). Not sure what
to do about that...
> This is also handy in that you can set flags or something before getting
> back to the main expression. This makes EH more like a "footnote" to
> the code than anything I've used before.
Indeed, nice metaphor.
Larry
