Unexpected EOFException in ImageReaderSpi.canDecodeInput

[Martin Desruisseaux]

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