As many developers have reported in the past, the Image.network constructor throws an exception whenever an HTTP error occurs (be it a 4xx error, 5xx error, or a SocketException). This is done in spite of the fact that there are many ways in which the developer can provide fallbacks when such an error occurs; using the built-in errorBuilder for example, or by attaching an ImageStreamListener and implementing its onError handler.

An HTTP error is not a failure of the code, and so should not throw an exception. Not when there are already hooks in place to allow the developer to handle the errors in a non-destructive manner. Throwing an exception is a major overkill and it completely breaks the app.

Use case

To understand the severity of this, try this:

1. Build an app with a ScrollView that loads many Image widgets at the same time (ala Pinterest). (You can start with the sample app from the errorBuilder docs - create --sample=widgets.Image.errorBuilder.1 mysample - and just modify it to insert multiple Image.network widgets into a ScrollView.)
2. Block network traffic if not using the sample app, to ensure HTTP errors will trigger.
3. Run the app.

What you'll end up having is an app that throws one exception after the other and a locked interface (E.g. no gesture responses on the scroll view).

Expected Behavior

An HTTP request should never throw an exception on failure. It should instead fail gracefully, providing onError hooks, and allow the UI and logic to continue their execution.

Proposed solution

1. Stop throwing exceptions on HTTP errors.
2. Add an onError handler to the Image.network constructor.
3. Modify the docs to encourage developers to either implement errorBuilder or an ImageStreamListener with an onError handler.