Exception handling in futures is clumsy.

[DartBot]

This issue was originally filed by sammcca...@google.com

---

* Requires me to register two handlers

• Can't use try/catch
• Ability to omit an exception handler is problematic: see issue Future: Setting a completeException on a Completer lost if the fulfillment of the future is synchronous.  #1115

What about

someAsyncMethod().then((result) {
  try {
    print(result.value);
  } catch (SomeException e) {
    print("Oh no, error!");
  }
});

'result' could be the original Future object, or some Completion<T> object (which would probably play nicer with a unified event/future async model)

[sethladd]

cc @sigmundch.
Removed Type-Defect label.
Added Type-Enhancement, Area-Library, Triaged labels.

[DartBot]

This comment was originally written by sammcca...@google.com

---

Additional shortcomings from more experience:
The hidden-statefulness of Futures makes composability really bad. (In this case the hidden state is: whether there is an error handler already attached which will ultimately swallow an error that occurs).
For example, given an arbitrary future, there is no way to trigger a callback whenever it completes, and no way to know whether an error handler you attach is dead.

One workaround would be to add a Future.finally(void callback()) that would execute after all .then()s and .handleException()s regardless of the completion outcome.
That wouldn't break existing code, but would allow users to ignore the problematic behaviour by using:

    future.handleException((e) => true);
    future.finally((){ ... });

Would you accept a patch for this?

[DartBot]

This comment was originally written by sammcca...@google.com

---

Sorry, I forgot the BUG= line in the code review, but this is fixed in https://code.google.com/p/dart/source/detail?r=8303

[whesse]

I disagree with the way that any exceptions in the onComplete handler are silently ignored. I think there is a principle that no exceptions are silently swallowed anywhere in Dart. I had a hard time finding and debugging errors in my onComplete handlers because of this.

This is now filed as part of bug 4127.

[lrhn]

No plans to change the Future de# this way.
Each handler on a future is notified individually, there is no "after all handlers are notified" time that you can use. You can add new handlers to a future after it has completed.

The onComplete will not swallow errors unless a new error is introduced. In that way it works the same as a try/finally where the finally-block throws.

You can now either use async functions to use try/catch on awaited futures, or you can use Result.capture from package:async to capture the result of a future into a single object that can hold either a value or an exception.