On 01/02/2023 23:24, Kohei Yoshida wrote:
On 01.02.2023 02:31, Stephan Bergmann wrote:
On 01/02/2023 02:37, Kohei Yoshida wrote:
I just borrowed your solution and called it "resolved", though I
believe, even without that explicit try catch block, it would just
terminate all the same?
Yes. But without the explicit try catch block it would help compiler
runtimes report the place where the (effectively uncaught, and
presumably "this can't happen"-style unexpected) exception was
actually thrown. I'm not convinced Coverity Scan is doing us a
service here, overall.
Gotcha. Thinking about this a bit, maybe it's better not to have that
explicit try catch block I just added. Let me know what you all think.
I assume that this is actually a false positive, i.e., that while
delete_element_blocks can throw in general, it is guaranteed that it
will never throw in that invocation from within ~multi_type_vector.
Otherwise, it wouldn't be sound to introduce the try/catch/terminate
here anyway. Isn't there a way to mark that false positive with an
appropriate Coverity Scan comment?
