From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fdb77,5f529c91be2ac930 X-Google-Attributes: gidfdb77,public X-Google-Thread: 1108a1,59ec73856b699922 X-Google-Attributes: gid1108a1,public X-Google-Thread: 11232c,59ec73856b699922 X-Google-Attributes: gid11232c,public X-Google-Thread: 103376,583275b6950bf4e6 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-05-02 01:24:38 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!nntp.cs.ubc.ca!fu-berlin.de!uni-berlin.de!dialin-145-254-036-133.arcor-ip.NET!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.java.advocacy,comp.object,comp.lang.ada,misc.misc Subject: Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died) Followup-To: comp.lang.java.advocacy Date: Fri, 02 May 2003 10:26:32 +0200 Organization: At home Message-ID: References: <9fa75d42.0304230424.10612b1a@posting.google.com> <9fa75d42.0304240446.493ca906@posting.google.com> <3EA7E0E3.8020407@crs4.it> <9fa75d42.0304240950.45114a39@posting.google.com> <4a885870.0304291909.300765f@posting.google.com> <416273D61ACF7FEF.82C1D1AC17296926.FF0BFD4934A03813@lp.airnews.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: dialin-145-254-036-133.arcor-ip.net (145.254.36.133) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: fu-berlin.de 1051863877 14231368 145.254.36.133 (16 [77047]) User-Agent: KNode/0.7.1 Xref: archiver1.google.com comp.lang.java.advocacy:63031 comp.object:62525 comp.lang.ada:36838 misc.misc:13888 Date: 2003-05-02T10:26:32+02:00 List-Id: Kaz Kylheku wrote: > Ada exceptions are a laughably low-level mechanism, that is about as > powerful as some of the feeble C macro packages that wrap up setjmp > and longjmp. Some of those packages are more powerful because they can > subclass errors into categories. Can those macros finalize things going out of scope? > Modern languages represent errors > using class hierarchies, Probably, what is actually needed, is just an order relation on the exception type. A subclassing relation induces an order, but isn't it a bit too much for that? > allowing handlers to express more or less specific matches. It is arguable whether exceptions should to be of any type. C++ way to do it has a heavy price. C++ exceptions are very inefficient and there are problems with dynamic memory allocation when an exception happens. Consider all issues which might appear in a multitasking and/or multiprocessor environment. > An error handler should preserve the full dynamic context of the > situation---this is how exception vectors in processor architectures > work. When an interrupt happens, the currently running thread is not > unwound all the way back to the operating system! Ada's exception propagation mechanism is far more complex than you describe it. For example, when an exception is raised at a rendezvous point it is propagated in both the caller and the callee. Let you want to return exactly to the point where it was thrown, how could you do it? > No, the exception > pushes new information onto the stack, and can later restart the task > exactly where it left off. For example, you hit a page fault, the > operating system's handler makes the page available, and then restarts > the process, so the access instuction is tried again and succeeds this > time. ... resuming a real-time task after 1.5 hours of trying to read a bad block! > Unwinding on error is the stupidest possible thing to do; it > allows for containment, but not recovery. What can be recovered needs no exception. Exceptional state is when *nothing* useful can be done in the current context. The word nothing excludes any "recovery" for the given context. It is gone and dead. > I would be tempted to hack up my own error system based on registering > handler *functions*, and using the exceptions as the final step in > error handling, to unwind to a restart point. The Ada exception > handlers resemble Common Lisp's restarts in some ways, most notably > that they are points in the dynamic context identified by symbols. > But, sadly, there is no way to introspect over them; in other words, > to compute a list or otherwise enumerate or iterate over the handlers > that are visible in a given dynamic context. So you can't implement > logic like ``if there is a handler for Foo exception, then raise it'' > which would represent the idea ``if a Foo way of continuing is > available at this point, let's choose it''. This has nothing to do with exceptions. It is rather a typical case for a dispatching subroutine = "handler". Again, the decision whether "a Foo way is available" *can* be made in the current context. So it is *not* an exceptional state at all. It would be just a bad design to try to express it in exceptions. > A WHEN clause in the > exception block also has no way of returning back to the raise point > to show that it's declining to handle the error. Nevertheless, with > this approach, one could perhaps implement some rudimentary error > recovery protocols. > > For example, suppose that we agree on a very simple convention that we > will have two ways of continuing after an error: an Abort and Retry. > When I call your module and it encounters a problem, it calls a > handler callback in my module. No unwinding takes place yet. In my > module I then decide (perhaps with the help of a user) whether to > retry the operation or abort, and raise the appropriate exception, > which passes back to your code. If I raise Retry, then the operation > which failed will be tried again. Of course, I can raise some third > exception that your module doesn't know about, to obtain a non-local > exit that bypasses your module entirely. In other words, exceptions > are really restart choices; the last step in the protocol for > recovering from an error situation, based on making some sort of > informed decision at a higher layer combined with advice at the lower > layer. If this is just a callback, then everything is already here. If it is something else, which has to run on both contexts, then how it is supposed to work? Consider a callee and a caller of one of its entry points running on different processors ... > I'm warmly entertained, by the way, by how the string returned by > Exception_Message may be truncated to 200 characters. Ah, assembly > language and its fixed buffers. Of course heap allocation of an Out_Of_Memory exception object would be much better ... -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de