error handling

[Victor Shoup]

Thanks Marc, 
This all looks very good! 

Marc Glisse <marc.glisse at inria.fr> 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
>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

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