OOM exception handling is gonna be hard to implement, as GMP does not provide any mechanism to recover from memory errors. You can replace the GMP memory management functions but the usual problem with that approach is that you might be potentially interacting with other packages which might also want to override the default functions. Another problem is that IIRC throwing C++ exceptions from C is undefined (or maybe implementation-defined?) behaviour.
In any case, exceptions are the way to go when you program in C++. A well-coded C++ program should state precisely what level of exception safety the routines provide (no-throw, strong, basic), and how and what a routine can throw. Ideally you would want strong exception safety always - this is quite doable but sometimes for the sake of performance basic exception safety is a good compromise. Of course anything involving move semantics should be marked noexcept. Another typical suggestion is always to use RAII patterns when coding routines that can throw - that way you are guaranteed that any resource is properly cleaned up before exiting the function through an exception. C++11 also has good support for handling exceptions in threads, including transporting exceptions between threads. In particular, using an std::future for managing the return value of (or the exception thrown within) a thread is pretty handy. Cheers, Francesco. On 12 November 2014 00:05, Jean-Pierre Flori <jpfl...@gmail.com> wrote: > > > On Tuesday, November 11, 2014 11:55:49 PM UTC+1, Volker Braun wrote: >> >> What kind of error states are we talking about? divide by zero and out of >> memory? >> >> Exactly, that is exactly the kind of stuff Victor mentioned. > > >> IMHO a C++ library should just throw C++ exceptions, thats what they are >> here for. If only for better readability -> less bugs. If you declare >> methods with "except +" to Cython then they will automatically be converted >> into Python exceptions, so its also very convenient for us. Pynac uses that >> all the time. >> >> Pretty much the only potential downside are rumors that exceptions might >> possibly hinder the optimizer. Though I've never seen that in a reasonable >> benchmark. While that is certainly a possibility, it would just be an >> optimizer bug. All reasonable C++ compilers uses a zero-cost model so its >> at least as fast as handling / returning some error flag. What _is_ >> expensive is when an exception occurs, but in C++ you are not supposed to >> use exceptions for program flow like in Python. >> >> >> >> On Tuesday, November 11, 2014 10:15:44 PM UTC, Jean-Pierre Flori wrote: >>> >>> Dear all, >>> >>> As you must have noticed, Victor Shoup just released a new thread safe >>> version of NTL. >>> >>> He also took the opportunity to ask me (and surely a bunch of other >>> people) what would be expected from exception handling in NTL >>> Currently NTL just prints something and then aborts. >>> Note that we patch that in Sage to call one of our own functions and >>> avoid aborting. >>> I'm no C++ expert and don't usually play with exceptions, so I don't >>> have anything that sart to say. >>> But your comments/ideas/suggestions are more than welcomed. >>> I can gather them and forward them back to Victor. >>> >>> Best, >>> JP >>> >> -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
