Future#handleException is too long!

[DartBot]

This issue was originally filed by [email protected]

---

This may seem trivial, but this method name really bugs me:
 * it's inconsistent with then(), which should rather be handleResult()
 * its long name (especially by contrast with 'then') suggests that it's somewhat obscure, when in fact it should usually be called on every Future.

What about
getFooAsync().then(...).except(...)?

[DartBot]

This comment was originally written by [email protected]

---

I was thinking about the name, came up with 'but', 'thrown' or 'caught', but none of them is particularly nice. 'except' FTW!

[DartBot]

This comment was originally written by @seaneagan

---

How about:

defend
guard
protect
shield

I also like 'recover' except it makes it sound like the exception already happened when it is called.

[sethladd]

except() works for me.

---

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

[justinfagnani]

How about catch() ?

[DartBot]

This comment was originally written by [email protected]

---

else() ?

[sigmundch]

I hope we can find something that is easy to understand also it we use it alone (without 'then').

In particular, 'except' reads nice when using a fluent API (.then().except()), but it's harder to understand in code like this:
  Future f = ...;
  f.except((err) { });

We can't use 'else' and 'catch' because they are reserved words in Dart.

Here are some other proposals I've heard:

• use 'onX' methods, like onError (renaming 'then' to 'onComplete' or 'onValue'):
    future.onError(...);
• combine error and non error by passing the future (and not the value) to the 'then' method:
    future.then((fut) { if (fut.hasError()) { ... } });
• pass the error handling callback as a second (optional) argument to 'then':
    future.then((v) { },
                (e) { });

Any other ideas?

---

cc @munificent.

[DartBot]

This comment was originally written by [email protected]

---

Personally, I like passing the error callback as a second (optional) argument.

From my experience writing something quite similar in another language, we actually ended up with a third (optional) 'finally' callback. So:

future.then((v) {}, (e) {}, () {})

-Ross

[munificent]

• use 'onX' methods, like onError (renaming 'then' to 'onComplete' or 'onValue'):
  future.onError(...);

I worry that this is confusing because that pattern is used for event handlers elsewhere.

• combine error and non error by passing the future (and not the value) to the 'then' method:
  future.then((fut) { if (fut.hasError()) { ... } });

That works, but then you can't really type the callback's argument in a useful way.

• pass the error handling callback as a second (optional) argument to 'then':
  future.then((v) { },
                (e) { });

I like this. Maybe name it "except":

file.readText().then((text) {
  print(text);
}, except: (err) {
  print('Could not read: $err');
});

[DartBot]

This comment was originally written by [email protected]

---

I hope we can find something that is easy to understand also it we use it alone (without 'then').

I don't think 'then' is particularly easy to understand - to make it obvious what the callback is for, it would need to be 'onResult' or 'handleResult'.
But I think that for very common operations, terseness and memorability are more important than being self-describing, thus then() and except().

I agree that an optional 'except' parameter would be an improvement over what we have now, but I think renaming handleException is still necessary and (once we have cascades) sufficient.

[DartBot]

This comment was originally written by @seaneagan

---

'except' doesn't make sense to me. It has various forms:

Preposition: Not including; other than.

Conjunction: Used before a statement that forms an exception to one just made: "I didn't tell him anything, except that I needed the money".

Verb: Specify as not included in a category or group; exclude.

... and none of these seem to match the idea of registering an exception handler.

'catch' is perfect, if only it weren't a keyword, :)

I like passing both success and error handlers to the same method, one nit though is that passing two function literals to the same method can make it hard to tell where one starts and the other begins, but that can mostly be avoided with an idiomatic line break style.

It would nice to stick to verbs for methods, some alternatives to 'then' would be:

schedule
plan
follow
prepare

[DartBot]

This comment was originally written by [email protected]

---

I don't think 'then' is particularly easy to understand
It would nice to stick to verbs for methods, some alternatives to 'then' would be:

C# Tasks use 'ContinueWith' which is a bit long but perhaps 'continue' is a possibility

[DartBot]

This comment was originally written by [email protected]

---

An alternative is unifying the success and failure callbacks:
http://code.google.com/p/dart/issues/detail?id=3047

[DartBot]

This comment was originally written by [email protected]

---

+1 for something along the lines suggested in #­3047. It would reduce the number of callbacks, the familiar form of try-catch could be used, including finally, and wouldn't make it necessary to remind people to use an alternative pattern all the time.

[andersjohnsen]

As part of the Future redesign, the members where renamed accordingly:

  .handleException -> .catchError
  .onComplete -> .whenComplete

---

Added Fixed label.