Yuval Kogman wrote: >On Fri, Oct 07, 2005 at 02:31:12 -0400, Austin Hastings wrote: > > >>Yuval Kogman wrote: >> >> >> >>>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. > >
Yet here we are discussiong abnormal 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. > > No, it isn't. It's *one way* to do this. Any mechanism which transfers control to your error-recovery code in such a way that can cause an uplevel return of a substituted value is the "bare metal support we need". You're conflating requirements and design. I suggested an alternative *design* in my prior message, to no avail. Try this instead: You overload the global 'die' with a sub that tries to decode the error based on its arguments. If it cannot comprehend the error, it invokes P6CORE::die(). If it comprehends the error, it tries to resolve it (querying the user, rebooting the machine to free up space in /tmp, whatever) and if successful it returns the fixed value. But wait! This requires that everyone do "return die ..." instead of die..., and we can't have that. So you add a source filter, or macro, or tweak the AST, or perform a hot poultry injection at the bytecode level, or whatever is required to convert "die" into "return die" whereever it occurs. Et voila! No exceptions are caught, no continuations are released into the wild. And yet it flies. Much like the hummingbird it looks a little awkward, and I'm way not sure that munging bytecodes is necessarily a better idea. But the point is that "resuming from an exception" (or appearing to) is not bound to "implemented with continuations". =Austin "Et vidi quod aperuisset Autrijus unum de septem sigillis, et audivi unum de quatuor animalibus, dicens tamquam vocem tonitrui : Veni, et vide. Et vidi : et ecce camelus dromedarius, et qui scriptat super illum, habebat archivum sextum, et data est ei corona, et exivit haccum ut vinceret." Apocalypsis 6:1 (Vulgata O'Reilly)
