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,6bf9d4ba0cfd8cb6 X-Google-Attributes: gid103376,public From: Hyman Rosen Subject: Re: Announce: OpenToken 2.0 released Date: 2000/02/01 Message-ID: #1/1 X-Deja-AN: 580535648 Sender: hymie@calumny.jyacc.com References: <3890C62B.18309585@telepath.com> <876unj$jcs$1@nnrp1.deja.com> <87799k$aai1@news.cis.okstate.edu> X-Complaints-To: abuse@panix.com X-Trace: news.panix.com 949443765 15669 209.49.126.226 (1 Feb 2000 22:22:45 GMT) Organization: PANIX Public Access Internet and UNIX, NYC NNTP-Posting-Date: 1 Feb 2000 22:22:45 GMT Newsgroups: comp.lang.ada Date: 2000-02-01T22:22:45+00:00 List-Id: "Vladimir Olensky" writes: > If language has well defined and constructed exceptions > mechanism without much overhead then there is nothing > wrong in using exceptions as condition signals or events. Because of the way exceptions work, unwinding the stack and calling finalizers on controlled objects along the way, it's rarely the case that they are implemented "without much overhead". I understand that some Ada compilers will watch for exceptions which are thrown and caught locally, and turn them into efficient code, but that's not something to rely on for portability. The general implementation strategy for exceptions is to make their use as cheap as possible as long as they are not actually thrown, but to allow considerable overhead once they are thrown.