Yes, that is an issue. Writing exception-safe code is hard, as I'm finding out... Of course, I'll have to provide a way to turn off/on exceptions, both at compile time and at run time.
On Thursday, November 13, 2014 12:04:53 PM UTC-5, Robert Bradshaw wrote: > > 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 <blues...@gmail.com > <javascript:>> 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 <jpf...@gmail.com > <javascript:>> 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+...@googlegroups.com <javascript:>. > >> To post to this group, send email to sage-...@googlegroups.com > <javascript:>. > >> 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+...@googlegroups.com <javascript:>. > > To post to this group, send email to sage-...@googlegroups.com > <javascript:>. > > 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.
