" You can call deal_II_exceptions::disable_abort_on_exception(); which converts the call to abort() to raising an actual exception. " This worked indeed.
" But I do want to ask what you plan to do if you derefernce an end-iterator. " I see your point, let me briefly sketch what I want to do: I have an interpoland to which I attach a triangulation. When I want to evaluate the interpoland at a real point, I first call GridTools::find_active_cell_around_point to find the cell where the point lives along with the unit cell coordinates. Then, I call the .reinit function to actually evaluate values, gradients, ... of the interpoland. However, it may be the case that the evaluation point is outside the domain of the triangulation, in which case .reinit aborts the program, for the reasons you mentioned. In those cases, I also want to abort the program but with a more meaningfull message. In particular, I want to inform the user about the domain of the interpoland, the point where evaluation failed, and workarounds how to circumvent such out-of-bound evaluations,... I want to do this by throwing on instance of a class that derives from dealii::ExceptionBase in the catch block. Does that make sense? Or do you see a better solution, like checking cell->status() right after GridTools::find_active_cell_around_point? Best, Simon Am Mi., 2. Aug. 2023 um 18:51 Uhr schrieb Wolfgang Bangerth < bange...@colostate.edu>: > On 7/30/23 11:20, Simon Wiesheier wrote: > > > > Of course, it does not make sense to dereference such an iterator. > > That's the reason why I wanted to catch this operation, and do something > else > > instead. In my case, aborting the program is absolutely not necessary as > I > > would have a workaround. > > > > But, if I understand you, there is no way for me to catch the exception > from > > my question, right? > > You can call > deal_II_exceptions::disable_abort_on_exception(); > which converts the call to abort() to raising an actual exception. > > But I do want to ask what you plan to do if you derefernce an > end-iterator. > That should simply never happen -- it's a bug in the program to do this, > comparable to a segmentation fault when dereferencing a NULL pointer. The > right approach is to ensure that that doesn't happen, not to come up with > a > backup plan to do something else if it does happen. > > Best > W. > > -- > ------------------------------------------------------------------------ > Wolfgang Bangerth email: bange...@colostate.edu > www: http://www.math.colostate.edu/~bangerth/ > > > -- > The deal.II project is located at http://www.dealii.org/ > For mailing list/forum options, see > https://groups.google.com/d/forum/dealii?hl=en > --- > You received this message because you are subscribed to the Google Groups > "deal.II User Group" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to dealii+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/dealii/a025ea76-c601-e504-a586-a9e54b3e20bd%40colostate.edu > . > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/CAM50jEtwn6wJEUGridcnAQzRZpGo6dg2JzzN-UW-MmuRbqgvjQ%40mail.gmail.com.
