Fix VTK forcibly aborting application instead of throwing error

Development
,
1

VTK currently forcibly aborts an application if no screen is available. Having a library like VTK call std::abort is significantly worse than having it throw errors since for std::abort, it is not possible to catch the error and show any meaningful information to users - in this case e.g. to users without a screen on HPC systems. Some applications are even commonly run as part of batch scripts and use VTK just for visualization in one step that could be skipped if VTK wouldn’t forcibly abort the software.

The fix for it throwing an error instead was suggested in the merge request https://gitlab.kitware.com/vtk/vtk/-/merge_requests/10500 and discussed in https://gitlab.kitware.com/vtk/vtk/-/issues/19075 with @sankhesh , @cory.quammen and Mathieu Westphal.

As requested in the above merge request, I am hereby opening a Discourse discussion regarding it.

2

As I stated there, I agree with @2xB that VTK should not ever call std::abort.

However, VTK should not throw exception either. VTK was never intended and designed around exceptions. exceptions can be used internally but should not be part of VTK API.

The std::abort should be replaced with a cleaner code path that do not rely on the VTK user catching an exception.

3

I believe in general this statement makes sense for GUI applications as long as the GUI is recoverable, but we are talking about a situation that is not recoverable where the GUI doesn’t even exist yet.

The difficulty is that library users somehow need to have a chance on knowing if launching the GUI window worked.

Since VTK just has 22 calls to std::abort but over 300 calls to just std::runtime_error alone, I so far thought that for unrecoverable situations, throwing an error is still reasonable. (The respective grep command I used 7 months ago to find these numbers is documented in https://gitlab.kitware.com/vtk/vtk/-/merge_requests/10500#note_1415332 ) If there are other options preferred, I would of course also be glad to see them in VTK, but since I think they are then very likely significantly less easy to implement, I think in that case someone from the VTK development team should be the person to implement them.

4

Are these not catched by VTK ?

5

Ah, it’s 259 occurrences when ignoring tests (git grep "throw std::runtime_error(" | grep -v "ThirdParty" | grep -v "//" | grep -v "*" | grep -v "Test" | grep -v "test" | wc -l).

Let’s take vtkArrayReader. Is it an exposed class? I think so. Still it can throw many exceptions. To be fair, most std::runtime_error exceptions are thrown in IO, e.g. in Rendering, there are only two.

Again, if there is a better solution and someone is available to implement it, I would be glad! I’m just looking forward to any improvement I can work with in my application, which is what the merge request would provide me (I am very aware that I have to wait potentially quite long for the change to get packaged and distributed to all users as well).