error handling

Victor Shoup shoup at
Wed Dec 17 12:43:51 UTC 2014

Thanks Marc, 
This all looks very good! 

Marc Glisse <marc.glisse at> wrote:
>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
>that option as a last resort.
>> About C++03 vs C++11:  I'd say for stuff like this, just go with
>> if that is significantly more convenient.
>Here I am trying to understand if it is pointing at a buglet in the C 
>> 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
>>    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
>>    in standard C++ header files, because right now, I don't expose
>>    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
>>    in a separate header file...
>>    Failing that, I can probably find a work-around (and maybe dumping
>>    into some NTL header files is anyway not a big deal).
>>    Anyway, it's something to think 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
>>    My current thinking is to throw bad_alloc for memory allocation
>>    and runtime_error (possibly subclasses thereof) for everything
>>    but I'm not sure.
>As a user I would just catch(...) and not bother further, but in any
>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
>there is anywhere else, but I don't know every part of GMP.
>Marc Glisse

Sent from my Android device with K-9 Mail. Please excuse my brevity.

More information about the gmp-discuss mailing list