Message-ID: <361CEFE8.E1BE795D@inetlab.com>
Date: Thu, 08 Oct 1998 23:01:28 +0600
From: Ilya Ryzhenkov <orangy AT inetlab DOT com>
Organization: iNetLab
X-Mailer: Mozilla 4.03 [en] (Win95; I)
MIME-Version: 1.0
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
CC: djgpp workers list <djgpp-workers AT delorie DOT com>
Subject: Re: DLM v2.0 soon! ;))
References: <Pine DOT SUN DOT 3 DOT 91 DOT 981008144727 DOT 1499K-100000 AT is>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Eli Zaretskii wrote:
> First, what's wrong with installing a handler for SIGABRT and doing
> whatever you want in there?  SIGABRT is just a signal, so it can be
> caught.
Unhandled exception is not the only reason of SIGABRT, so I should
trace back the stack to find if it was caused by call to throw and
it is not as easy in DLM environment. And there is a pitfall - 
SIGABRT can be raised, for example, by exception handler and there
is no way to distinguish between this two events. Sure, there is a 
way but it is not so wonderful coding ...
 
> And second, what's wrong with the bahavior of `abort' in v2.02?  It
> prints the standard DJGPP traceback, which is a functional equivalent
> of a core dump (or at least as close as you can get without supporting
> core dumps ;-).  In other words, it allows you to know where exactly
> was `abort' called.  It even prints the location where SIGABRT was
> raised for your convenience.  On Unix, `abort' actually dumps core.
> Isn't that what unhandled exceptions should do?
I don't know what Standard says about unhandled exception 
(btw, can anyone point me to newest standard on the Net?), for
sure the process must abort, but what about messages ?
Isn't it more clear to get
"Abort! Unhandled exception at ...blah-blah..."
and print trace back _from the point of exception throw_ ?

============================
Ilya P. Ryzhenkov aka Orangy
Fido   : 2:5000/120.7
E-mail : orangy AT inetlab DOT com
   ICQ : 17942172