On Fri, Oct 07, 2005 at 02:31:12 -0400, Austin Hastings wrote:
> Yuval Kogman wrote:
>
> >On Thu, Oct 06, 2005 at 14:27:30 -0600, Luke Palmer wrote:
> >
> >
> >>On 10/6/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >>> when i can't open a file and $! tells me why i couldn't open, i
> >>> can resume with an alternative handle that is supposed to be the
> >>> same
> >>>
> >>> when I can't reach a host I ask a user if they want to wait any
> >>> longer
> >>>
> >>> when disk is full I ask the user if they want to write somewhere
> >>> else
> >>>
> >>> when a file is unreadable i give the user the option to skip
> >>>
> >>>
> >>I'm not bashing your idea, because I think it has uses. But I'll
> >>point out that all of these can be easily accompilshed by writing a
> >>wrapper for open(). That would be the usual way to abstract this kind
> >>of thing.
> >>
> >>
> >
> >
> >
> Writing a "wrapper" may be the implementation mechanics:
>
> sub safe_open()
> {
> call;
> CATCH { when E::AccessDenied { return show_user_setuid_dialog(); }}
> }
>
> &open.wrap(safe_open);
>
> But this is just one way to do it, and it fails to provide for "helping"
> other people's code: Yuval's GUI environment would offer to fix the
> problem for ALL file related calls (open, dup, popen, ad nauseum), and
> would not have to worry about the order in which calls are wrapped. But
> see below.
>
> >Stylistically I would tend to disagree, actually. I think it's cleaner to
> >use exception handling for this.
> >
> >Also, this implies that you know that the errors are generated by open. This
> >is OK for open(), but if the errors are generated from a number of variants
> >(MyApp::Timeout could come from anywhere in a moderately sized MyApp), then
> >wrapping is not really an option.
> >
> >
>
> I think that what your proposal *really* requires is uniformity. There
> are other ways to get the same behavior, including an abstract factory
> interface for exception construction (would provide "virtual
> constructor" for exceptions, so permitting userspace to insert a 'retry'
> behavior), but it has the same vulnerability: the p6core must cooperate
> in uniformly using the same mechanism to report errors: throw, fail,
> die, error, abend, whatever it's eventually called.
We have:
die: throw immediately
fail: return an unthrown exception, which will be thrown
depending on whether our caller, and their caller - every scope
into which this value propagates - is using fatal.
This is enough for normal exception handling.
As for recovery - the way it's done can be specialized on top of
continuations, but a continuation for the code that would run had
the exception not been raised is the bare metal support we need to
do this.
Where this gets taken further by (IMHO overly abstract) exception
handling libraries and standardization is a question that
application development kits (e.g. Catalyst, GTK, Cocoa) must
develop a policy for.
> return recover_from_error([EMAIL PROTECTED])
what does this do?
--
() Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker &
/\ kung foo master: /me beats up some cheese: neeyah!!!!!!!!!!!!!!!!!
pgp3FUsw93RD9.pgp
Description: PGP signature
