TSa wrote: > > The view I believe Yuval is harboring is the one examplified > in movies like The Matrix or The 13th Floor and that underlies > the holodeck of the Enterprise: you can leave the intrinsic > causality of the running program and inspect it. Usually that > is called debugging. But this implies the programmer catches > a breakpoint exception or some such ;) > > Exception handling is the programmatic automatisation of this > process. As such it works the better the closer it is in time > and context to the cause and the more information is preserved. > But we all know that a usefull program is lossy in that respect. > It re-uses finite resources during its execution. In an extreme > setting one could run a program *backwards* if all relevant > events were recorded! >
The current state of the art dictates that exceptions are to be avoided when it is possible to handle the error in-line. That "exceptions should only be used for exceptional cases, and anything you encounter in the manual pages is not exceptional." I don't agree with this, because it is IMO effectively saying "We had this powerful notion, but it turned out to be difficult to integrate post-hoc into our stack-based languages, so we're going to avoid it. Rather than admitting defeat, though, we're going to categorize it as some kind of marginal entity." I don't see exceptions as necessarily being outside the intrinsic causality of the running program. They are non-traditional forms of flow control: event-based programming, if you will, in an otherwise sequential program. We do much the same thing when we talk about coroutines: violate the traditional stack model. We do the same thing again when we talk about aspects: de-localize processing of certain (ahem) aspects of the problem domain. The telling part of aspects, though, was the the first popular implementation (AspectJ) required a preprocessor and a special markup language to implement. Why? Because nobody uses extensibility and Java in the same sentence. I guess aspects are traditional in that regard, though: remember CFront. Perl, OTGH, doesn't have the poor body-image or whatever it is that keeps people afraid to change the syntax. >> It can't be a method because it never returns to it's caller - it's > > > It beeing the CATCH block? Ahh, no. "It" in this case is the ".resume" call. My question was is <c>resume</c> a multi, an object method, or what? >> This is because the types of exceptions I would want to resume are >> ones that have a distinct cause that can be mined from the exception >> object, and which my code can unambiguously fix without breaking the >> encapsulation of the code that raised the exception. > > > Agreed. I tried to express the same above with my words. > The only thing that is a bit underspecced right now is > what exactly is lost in the process and what is not. > My guiding theme again is the type system where you leave > information about the things you need to be preserved to > handle unusual cicumstances gracefully---note: *not* > successfully, which would contradict the concept of exceptions! This is the classical view of exceptions, and so it is subject to the classical constraints: you can't break encapsulation, so you can't really know what's going when the exception occurs. The reason I like the "with" approach is that it lets us delocalize the processing, but does _not_ keep the "exceptions are violent, incomprehensible events which wrench us from our placid idyll" mentality. In that regard, exceptuations are "resumable gotos". =Austin
