Sage's wrapping of NTL should be just fine as long as it's declared in the Cython declarations, but there's a question of all the libraries that use NTL indirectly which may have more difficulty adapting to exceptions being thrown though their call stacks.
On Tue, Nov 11, 2014 at 3:48 PM, Francesco Biscani <bluesca...@gmail.com> wrote: > 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. -- 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.
