2000.07.25 08:43 "Re: TIFF Error handler", by Klaus Bartz
I had expected the libtiff code to return from the TIFFReadEncodedStrip() (or whatever) with an error indicator set, but that isn't what happens.
However, at this point I am somewhat hesitant to change the behaviour without a better understanding of why it is the way it is now. In particular, I am afraid that lots of developers are now depending on the fax3/fax4 decompression code to be quite forgiving of errors, and to try and go on and recover. If that is so, my making these errors suddenly fatal may be quite annoying.
I am cc:ing this message to the libtiff mailing list to see if anyone else has an opinion on what we should do. As I see it the options are:
My voting is:
Change the handling of warnings/errors in a manner, that the handler can trigger the reaction with its return value.
The users own warning handler should handle the given warning in it's preferred way, not libtiff. At this point it will be nice, if there is an error number ( additional to the message ) because coding a reaction dependant to a number is more easy as the same dependant to a string.
The use of warning/error handler in libtiff is dependant to the programer. In some code there are many calls to TIFFError ( e.g. tif_jpeg.c which parses most requirements ); other modules contains only a few calls to TIFFError ( e.g. tif_fax3.c which are really TIFFWarnings because the "giving up" is missing )
But nothing is perfect and a change could be the next "fall out" of libtiff - the last change ( 16 bit width/height changed to 32 bit ) has had some difficult side effects.
May be it will be better to leave things as they are. But do not terminate at an error always because a bad code word e.g. is not always fatal.
Klaus
-------------------------------------------------------------------
Dr. Klaus Bartz bartzkau@coi.de
COI GmbH / Abt. COI-S Erlanger Straße 62 D-91064 Herzogenaurach
Tel: +49 (9132) 82-3433 Fax: +49-9132-824959