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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,d4b13594b8779b99 X-Google-Attributes: gid103376,public From: mw@ipx2.rz.uni-mannheim.de (Marc Wachowitz) Subject: Re: Improving Ada Exceptions Date: 1997/11/03 Message-ID: <63ll1g$7f8$2@trumpet.uni-mannheim.de>#1/1 X-Deja-AN: 287816602 Organization: --- Newsgroups: comp.lang.ada Date: 1997-11-03T00:00:00+00:00 List-Id: ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) wrote: > throwing an exception object out of the scope of its class would be a > possibility that would have to be blocked some way. One way which would catch this problem in an (IMO) acceptable way, concerning both performace and language complexity, would be to require that the types of (potential) exception objects be subtypes of some particular type (say, Ada.Exceptions.Dynamic_Object), and then enclose a nested scope declaring such subtypes within an implicit handler for all such types declared immediately at its level, which then raises a particular exception (say, Ada.Exceptions.Out_Of_Scope) with appropriate information to find out the full name of the type of the original exception (this information would be intended for logging/debugging, similar to what you can get now). Any overhead for the implicit handler would only appear if a nested potential exception type is declared and the compiler cannot figure out that no such exception would otherwise escape its proper scope. (Note that in most environments, it's even possible to implement exceptions with zero time overhead as long as they are not raised, and the additional overhead for these implicit handlers if an innocent exception is raised would hardly be worth worrying about.) A somewhat different problem (which doesn't arise with CLOS, Java or C++) is that exception categories via subtyping tend to make most sense if you can put exceptions into several independent categories (i.e. multiple supertyping). While multiple views can be implemented reasonably well in Ada (and I even tend to prefer its tool-box approach to usual multiple inheritance in most situations), this particular problem seems to demand a more dynamic selection based on all available views, rather than only access through some known view. I'm not sure how this would best fit into the subtyping model of Ada-95 as we know it, and I'd fear that a naive attempt to use a single-inheritance hierarchy as exception categorization would easily lead to long-term trouble. Of course, if all you need is to get some more information about the exception through to the handler (e.g. which i/o-error happend with which file, what was the error code from the system call), it would be sufficient to associate an arbitrary object (with the above safety net) with an exception, but still select exception handlers only based on an explicitly named exception - similar to the way Modula-3 does it (which does have garbage collection, and doesn't need such a safety net for data, though it's still limited for nested procedures, which cannot be assigned to any variable at all, but only passed as procedure argument). -- Marc Wachowitz