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>
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

- Raw text -