2020.08.11 00:56 "Re: [Tiff] exceptions in TIFFSetField not being caught?", by Bob Friesenhahn

My application that uses LibTIFF is a high-speed image capture system.

I'm trying to harden it against disc-access issues (say, failed SSD write or storage disconnects)

My function for writing the file wraps all calls (TIFFOpen, TIFFSetField, TIFWriteScanLine, TIFFClose) within a single try/catch block.

These are C language function calls (not C++).

I'm testing various scenarios where I disconnect storage and am finding that if TIFFOpen succeeds but then the storage is disconnected during the write, TIFFSetFields will throw an exception inside tiff.dll rather than my own catch block catching it. I'm using C++ (MSVC17)

What do you mean by 'tiff.dll'? Is it the libtiff C library or something else?

Libtiff does have an optional C++ library but it only appears to provide the function TIFFStreamOpen(), which is not what you are using.

I've tried wrapping all LibTIFF calls individually with try/catch blocks and found that still tiff.dll will throw exceptions that my end doesn't catch.

Being a C language library, libtiff does not throw C++ exceptions. Instead it provides error and warning callback functions which can be used to synchronously be informed of errors and warnings.

It is not usually safe to throw C++ exceptions through C code so typically the callback function will save some information, and then there is a check for this information when the C function returns. If the libtiff C code is compiled using a C++ compiler (I have not tried that) then it is technically safe to throw a C++ exception, except for the huge problem that there would be massive memory leaks and other issues resulting from doing that. Unlike libpng and libjpeg, there is not an expectation that when an error occurs that the code can just 'jump' back to some point in the call stack (e.g. setjmp/longjmp).

If you were to throw a C++ exception through C code the program might crash or the C++ 'unhandled' exception fallback (which often does a programmed crash) may be used.

Any thoughts how to properly handle such exceptions?

First we would need to understand where those exceptions are coming from. :-)

Bob

Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt