error handling

[Marc Glisse]

On Mon, 15 Dec 2014, Victor Shoup wrote:

> You could have the RAII object provide an explicit "kill" method,
> which is called by the destructor or explicitly by TMP_FREE,
> and have the object keep track of whether "kill" has already been
> invoked on it.  That should solve your first problem: in normal
> execution, TMP_FREE will call "kill" before tests_end() has a
> chance to complain, and during stack unwinding, the destructor will
> take care of it instead.

That's the easy way, and precisely what I am trying to avoid. I am keeping 
that option as a last resort.

> About C++03 vs C++11:  I'd say for stuff like this, just go with C++11,
> if that is significantly more convenient.

Here I am trying to understand if it is pointing at a buglet in the C 
version.

> Anyway, do you think there are other exception-related issues to
> worry about?
>
> Some other things to consider:
>
>  * Maybe all calls to abort should be replaced (conditionally, with ifdefs)
>    with throwing an exception (not just men alloc failures)

Most, yes, but there aren't that many. The ASSERTs protected by 
WANT_ASSERT can remain as they are.

>  * What exception classes should actually be thrown? (I'm still trying to
>    figure this out for NTL...)
>
>    One thing I would request: you only throw exceptions that are declared
>    in standard C++ header files, because right now, I don't expose any
>    GMP interfaces in NTL header files, and it would be nice to keep it that way.
>    Failing that, I'd ask that you at least put GMP's exception class declarations
>    in a separate header file...
>    Failing that, I can probably find a work-around (and maybe dumping gmp.h
>    into some NTL header files is anyway not a big deal).
>    Anyway, it's something to think about...it would be a shame to get this far,
>    and then have something trivial like this mess things up...
>    What I certainly don't want to do is catch, translate, and rethrow GMP exceptions
>    in my interface layers: I just want to let GMP exceptions pass through my own code.
>
>    Anyway, it would be nice if we could coordinate on this just a bit...
>    My current thinking is to throw bad_alloc for memory allocation failure,
>    and runtime_error (possibly subclasses thereof) for everything else...
>    but I'm not sure.

As a user I would just catch(...) and not bother further, but in any case 
I was planning on using standard exceptions.

>  * Are there any other places in GMP that might cause exception safety problems?
>    Any other type of global state, etc.?

There might be global state in deprecated random functions, I don't think 
there is anywhere else, but I don't know every part of GMP.

-- 
Marc Glisse