Hello Philip
Le 17/05/2022 à 20:36, Philip Race a écrit :
Why is it unexpected ?
The purpose of ImageReaderSpi.canDecodeInput(Object) is to tell if the
source object seems to be supported by the reader. If the file is too
small, it is not supported by the reader. So a return value of false is
what I would expect from the method contract, because the method is
capable to provide a clear answer to the question "does it seems a valid
file?"
By contrast, I would expect IOException to be thrown only if an
unexpected error prevents canDecodeInput(Object) from fulfilling its
method contract, e.g. a lost of internet connection prevents the reader
to check the magic number. EOFException does not met that criterion for
the reason stated above.
The method declares that it throws IOException .. which if thrown
clearly means the stream can't be de-coded.
In my understanding of the method contract, if the stream can not be
decoded, this is indicated by a return value of false rather than an
IOException. In the context of ImageReaderSpi.canDecodeInput(Object), I
interpret IOException as an error that prevent the method from answering
the question "does it seems a valid file?"
But this fix is still putting it on each plugin to behave itself ..
and we already handle that in the ImageIO class
although I think it isn't perfect, as it still relies on co-operation
with regard to mark()
And if you call this directly, you can handle that just as well
yourself .. and still can't trust extra
plugins to behave ..,. so what is the use case for this fix ?
In my case I handle the search of ImageReader myself. Contrarily to
ImageIO I do not catch IOException, because it may be a serious error
that prevent the plugin from answering its question. The stream may now
be in a corrupted state (it is not always a local file; it can be on the
cloud, a database BLOB, etc), and continuing with other readers after
the initial error can cause a series of confusing error messages.
Instead I let the first IOException propagates. The meaning is very
different than "unsupported format".
I could catch the specific case of EOFException, but I don't because 1)
it relies on assumptions about how the plugin behave, 2) the input may
be an object other than ImageInputStream that we don't know how to mark,
and 3) EOFException can in some circumstances be a serious error (i.e.
EOFException occurring not in the stream given to the
canDecodeInput(Object) method, but is some auxiliary file that the
plugin needs to read). Only the plugin knows for sure if EOFException
means "unsupported format" or "serious error".
Regards,
Martin
