Image loading error reporting / handling

[steve.x.northover at oracle.com]

Very quickly I like the idea of an ImageLoader rather than adding new 
methods to Image.  The methods on Image that load now should be 
reimplemented to use the new class when it becomes available (but that 
will be a hidden implementation detail).

Steve

On 26/06/2012 11:18 AM, Lubomir Nerad wrote:
> Hi all,
>
> I have two feature requests which ask for better error reporting / 
> handling of image loading.
>
> The issues are:
>
> Make Image class support exceptions for both asynchronous and 
> synchronous loading
> (http://javafx-jira.kenai.com/browse/RT-17645)
> Image/Media need consistent error reporting
> (http://javafx-jira.kenai.com/browse/RT-976)
>
> Currently my idea of fixing them is through a new ImageLoader class.
>
> This class will have two sets of instance methods for image loading:
>
> Image load(...) - Used for foreground image loading. The difference 
> between them and the Image constructors would be that by default (!) 
> they will throw an exception if image loading fails [RT-17645] 
> (instead of returning an Image with error set to true).
>
> Image loadAsync(...) - Used for background image loading. Will throw 
> only when input arguments are null or invalid.
>
> Then there will be methods for registering image loading event 
> handlers [RT-976]. I can think of the following basic set of events:
>
> loading started (setOnLoadingStarted)
> loading progress (setOnLoadingProgress)
> loading finished
>     loading succeeded (setOnLoadingSucceeded)
>     loading failed (setOnLoadingFailed)
>
> They will use a new ImageLoadingEvent and possibly 
> ImageLoadingFailedEvent (with an added exception field). The 
> ImageLoadingEvent will report the image for which the event has been 
> generated (null for foreground images?).
>
> Image loading errors will be reported as runtime (!) 
> ImageLoadingException-s.
>
> ImageLoader instances will be created through constructor(s) with 
> possibility to pass some configuration parameters (for example the 
> maximum number of images being loaded at the same time).
>
> For "logging only" image loaders we might want to allow to configure 
> (constructor parameter? loadingFailedEvent.consume()?) whether the 
> load methods will throw ImageLoadingException or merely create Images 
> with error flags set (as is the case of Image constructors).
>
> This is just a basic outline of my proposal. We can focus on details 
> when/if this approach is accepted. Alternatively the issues could be 
> fixed by additional properties / methods on Image class. I didn't like 
> it, because the added properties would be useful only during short 
> period of the whole image lifetime and absolutely unusable for some 
> images (images created from scratch). I also think that the 
> ImageLoader approach makes uniform error handling of image loading 
> easier (one handler for several images instead of one handler per image).
>
> What is your preference / opinion about this?
>
> Thanks,
> Lubo
>