# Fix VTK forcibly aborting application instead of throwing error
**URL:** https://discourse.vtk.org/t/fix-vtk-forcibly-aborting-application-instead-of-throwing-error/13849
**Category:** Development
**Tags:** code, proposal
**Created:** [May 6, 2024, 3:52pm UTC](https://discourse.vtk.org/t/fix-vtk-forcibly-aborting-application-instead-of-throwing-error/13849 "2024-05-06T15:52:24Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@2xB](https://discourse.vtk.org/u/2xB)
#### Post date: [May 6, 2024, 3:52pm UTC](https://discourse.vtk.org/t/fix-vtk-forcibly-aborting-application-instead-of-throwing-error/13849/1 "2024-05-06T15:52:24Z")
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](https://gitlab.kitware.com/vtk/vtk/-/merge_requests/10500) and discussed in [https://gitlab.kitware.com/vtk/vtk/-/issues/19075](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.
---
### Author:  [@mwestphal](https://discourse.vtk.org/u/mwestphal)
#### Post date: [May 6, 2024, 3:56pm UTC](https://discourse.vtk.org/t/fix-vtk-forcibly-aborting-application-instead-of-throwing-error/13849/2 "2024-05-06T15:56:26Z")
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.
---
### Author:  [@2xB](https://discourse.vtk.org/u/2xB)
#### Post date: [May 6, 2024, 4:15pm UTC](https://discourse.vtk.org/t/fix-vtk-forcibly-aborting-application-instead-of-throwing-error/13849/3 "2024-05-06T16:15:55Z")
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](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.
---
### Author:  [@mwestphal](https://discourse.vtk.org/u/mwestphal)
#### Post date: [May 6, 2024, 4:17pm UTC](https://discourse.vtk.org/t/fix-vtk-forcibly-aborting-application-instead-of-throwing-error/13849/4 "2024-05-06T16:17:16Z")
> [@2xB](#):
>
> but over 300 calls to just `std::runtime_error`
Are these not catched by VTK ?
---
### Author:  [@2xB](https://discourse.vtk.org/u/2xB)
#### Post date: [May 6, 2024, 4:56pm UTC](https://discourse.vtk.org/t/fix-vtk-forcibly-aborting-application-instead-of-throwing-error/13849/5 "2024-05-06T16:56:49Z")
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).