-
2017.03.17 14:53 "Re: [Tiff] TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Bob Friesenhahn
-
2017.03.17 15:53 "Re: [Tiff] TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Dinesh Iyer
- 2017.03.17 16:07 "Re: [Tiff] TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Dinesh Iyer
- 2017.03.17 17:02 "Re: [Tiff] TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Bob Friesenhahn
-
2017.03.17 15:53 "Re: [Tiff] TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Dinesh Iyer
2017.03.18 10:53 "Re: [Tiff] TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Yakov Galka
On Fri, Mar 17, 2017 at 11:02 PM, <rleigh@codelibre.net> wrote:
If the libtiff core were to use a C++ TIFF class reporting errors via exceptions, it would be possible for this to be wrapped by the existing C API calling the C++ code in a try/catch block and reporting any thrown errors via the handlers.
The Error handlers are not the only way libTIFF reports errors. The no. 1 way it reports errors is through return values. The error and warning handlers are used more like a logging facility to output extra information about the cause of the errors and other issues. In particular when one of them gets called it is not supposed to abort the caller execution (either by throw or longjmp), because, among other things, the processing may continue and call the handlers multiple times. Therefore, exceptions are a not a substitute for them even if libTIFF were a C++ library.
--
Yakov Galka
http://stannum.co.il/