On Fri, 17 Jun 2022 13:41:38 GMT, Alexey Ivanov <[email protected]> wrote:
>> This getSoundbank method is called when we iterate over providers and check >> which can be used, unfortunately, that code is not ready for the IOException >> and we return "null" -> the next provider will be checked. This is a kind of >> compatibility quirk. > > Doesn't IOException mean the next provider is to be checked? > > That is the IOException could be handled in the iterator, its code may need > to be updated for that. Then the implementations of `getSoundbank(URL)` could > propagate the IOException too and eliminate duplicate code. > > `InvalidMidiDataException` isn't caught there, so the iterator code should > handle it. It is implemented in a way that if the bundled provider will fail we will try some next provider, but if the user add custom provider then getSoundbank(URL) will throw IOException signalling that something went wrong. I think InvalidMidiDataException should not be caught since that exception means the sound bank provider started to read the file, recognized that the file is supported, but then found the broken midi data. ------------- PR: https://git.openjdk.org/jdk/pull/8154
