www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1998/10/08/07:48:20

Date: Thu, 8 Oct 1998 14:47:46 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Ilya Ryzhenkov <orangy AT inetlab DOT com>
cc: djgpp workers list <djgpp-workers AT delorie DOT com>
Subject: Re: DLM v2.0 soon! ;))
In-Reply-To: <361BEB5D.EE65F6A4@inetlab.com>
Message-ID: <Pine.SUN.3.91.981008144727.1499K-100000@is>
MIME-Version: 1.0
Reply-To: djgpp-workers AT delorie DOT com

On Thu, 8 Oct 1998, Ilya Ryzhenkov wrote:

> Is there any _simple_ (i.e without rewriting libgcc parts)
> way to redefine standard behavior on unhandled exception ?
> It now just calls abort, which raises SIGABRT in turn and thus
> filling screen with uninformative text, far from real reason
> of halt.

My knowledge of C++ is abysmal, so the following might be downright
stupid.

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.

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?

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019