Unexpected EOFException in ImageReaderSpi.canDecodeInput

[Philip Race]

OK .. we can probably take the proposed change, but there's no guarantee 
it won't
still happen with 3rd party external plugins.

I've filed the bug for you : 
https://bugs.openjdk.java.net/browse/JDK-8287102

-phil.

On 5/18/22 2:47 AM, Martin Desruisseaux wrote:
> 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
>
>