[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gforth] exit() code in main.c
From: |
Anton Ertl |
Subject: |
Re: [gforth] exit() code in main.c |
Date: |
Tue, 22 Mar 2016 18:54:01 +0100 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
On Tue, Mar 22, 2016 at 06:21:05PM +0100, Bernd Paysan wrote:
> We have several places in main.c, where non-recoverable bugs happen, and we
> exit() on them. As Gforth can be used as library now, this is a bad idea - a
> library should never exit, so the only word that should be allowed to exit is
> main(). What to do?
Many of these occurences are conditions where recovery by the caller
of the library will not happen. So, just like a failed assertion
exits, it may be acceptable for the caller to exit when the image file
has the wrong format.
> C's exception handling with setjmp/longjmp is very poor, and can't be used
> outside the engine, where we pass the attempt to do some primitive exception
> handling to CATCH/THROW in Forth. So the probably best way is to define error
> return values for all the functions that may fail.
One could certainly have a
jmp_buf gforth_exit;
or something like it, and leave it to the caller of the library to
initialize it, and the gforth library longjmps to it from the places
that exit now.
A harder nut to crack is what to do about the error messages.
Currently many exit()s are preceded by fprintf(stderr,...). If we
don't want to exit() under these circumstances, we probably also don't
want to output the message. But if the caller decides to exit after
all, it will want to output the message. We could have a buffer for
doing this. But if the caller does not always exit, it may need some
easier machine-understandable indication of what the error is.
However, is it worth going to these lengths? Will there be any
applications other than Gforth itself that use Gforth as a library?
- anton