Skip to content

Updating the description of Future exception re-throwing #434

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Jul 15, 2015
Merged

Updating the description of Future exception re-throwing #434

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
7c50f31
Updating the description of Future exception re-throwing
demobox Jul 13, 2015
d929ca9
Updated description of fatal exception rethrowing
demobox Jul 14, 2015
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 10 additions & 9 deletions overviews/core/_posts/2012-09-20-futures.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -686,15 +686,16 @@ keeping this exception, the associated value is stored into the future or a prom
2. `ExecutionException` - stored when the computation fails due to an
unhandled `InterruptedException`, `Error` or a
`scala.util.control.ControlThrowable`. In this case the
`ExecutionException` has the unhandled exception as its cause. These
exceptions are rethrown in the thread executing the failed
asynchronous computation. The rationale behind this is to prevent
propagation of critical and control-flow related exceptions normally
not handled by the client code and at the same time inform the client
in which future the computation failed.

See [`NonFatal`](http://www.scala-lang.org/api/current/index.html#scala.util.control.NonFatal$)
for a more precise semantics description.
`ExecutionException` has the unhandled exception as its cause. The rationale
behind this is to prevent propagation of critical and control-flow related
exceptions normally not handled by the client code and at the same time inform
the client in which future the computation failed.

Fatal exceptions (as determined by `NonFatal`) are rethrown in the thread executing
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice. I think it would be great to also explain the rationality for rethrowing Fatals (fail fast).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the rationality for rethrowing Fatals (fail fast).

@viktorklang Could you explain that in a bit more detail? Unless I'm misunderstanding something, it's not the caller that fails fast, it's the worker thread that was actually executing the body of the Future.

Do you mean that the idea is to ensure that worker processes that are "irretrievably broken" die off as soon as a non-recoverable error is detected? In that case, how about the following?

"Fatal exceptions (as determined by NonFatal) are rethrown in the thread executing the failed asynchronous computation.This ensures that "broken" threads in the ExecutionContext fail fast, and can be replaced if necessary. See NonFatal for a more precise description of the semantics."

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's rethrown to the worker to escalate the problem upwards (instead of pushing the problem downstream to the consumer, which may or may not be listening or dealing with those kinds of problems).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@viktorklang Thanks for clarifying. In that case, how about:

"Fatal exceptions (as determined by NonFatal) are rethrown in the thread executing the failed asynchronous computation.This informs the code managing the executing threads of the problem and allows it to fail fast, if necessary. See NonFatal for a more precise description of the semantics."

?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SGTM

the failed asynchronous computation. This informs the code managing the executing
threads of the problem and allows it to fail fast, if necessary. See
[`NonFatal`](http://www.scala-lang.org/api/current/index.html#scala.util.control.NonFatal$)
for a more precise description of the semantics.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@viktorklang Updated. Let me know if you'd like me to squash the commits down.

Thanks!

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's up to @SethTisue :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's up to Seth Tisue :)

@SethTisue: ping..? ;-)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

to my knowledge, we're not picky about that in this repo.


## Promises

Expand Down