NVIDIA
Destructors must not throw exception
Reported by repalov, Aug 3, 2010 Some execution paths in Thrust can throw exception in destructor. It is lead to call terminate() if we already processing some exception (for example see http://www.gotw.ca/gotw/047.htm). For example I have next call stack:
device_vector::~device_vector vector_base::~vector_base contiguous_storage::~contiguous_storage contiguous_storage::deallocate ...
thrust::detail::device::cuda::free
and last function (free) throw exception which uncatched at all levels, including destructors.
Yes, I know that this error mean that I have broke CUDA device. But in any case - destructor must not throw. Delete comment Comment 1 by repalov, Aug 3, 2010 It is seems that solution is near Issue 37 (boost/std system_error).
Delete comment Comment 2 by project member jaredhoberock, Aug 3, 2010 Here is a dissenting opinion:
http://www.kolpackov.net/projects/c++/eh/dtor-1.xhtml
I don't believe there exists any reasonable alternative at this time: if we didn't allow ~device_vector to throw, how would we propagate the CUDA error to the user? CUDA errors are unrecoverable -- why does it make sense to silently continue program execution?
The dissenting opinion is very bad. The examples is very strange, moreover some of them is incorrect. The key idea of this paper is: "Even though Abort might be an overkill in some cases, it is the most ethical solution from all that were proposed." But why is it "most ethical"? Because if program continue it can damage some data? And the solution from author of paper is to terminate program. He lack the other possibility of damage data. Not by action, but by inaction.
For example if MS Word with document (which not saved for last 4-8 hours) is terminated when You start spell check because it can't close some file with dictionary in right way? Will You be the disappointed? I think You will be furious.
In MOST cases it is not to know that destruction is unsuccessfully. For example - if i destroy the mutex and OS call return error. It mean (among other) that this object can't be used any more. But I destroy mutex, so I won't use it in any case! So the fail in destructor is not important for me. The free of memory is same case. I don't really need to know about errors at "free". Because I won't use this memory any more.
If I broke the CUDA subsystem then I got error at the future. For example at next constructor. Constructor can (and must use) exceptions for inform about errors. But it is MORE preferable than terminating my program without any possibility to save user_data.
The solution, as I say in comment 1, probably is to use boost/std::system_error ( Issue 37 ). The free function must support unthrowing syntax, and destructor must use this syntax.
Forwarded from http://code.google.com/p/thrust/issues/detail?id=188
