Skip to content
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.

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

How to re-throw exceptions? #16

Closed
yhyh0 opened this issue Feb 11, 2014 · 5 comments
Closed

How to re-throw exceptions? #16

yhyh0 opened this issue Feb 11, 2014 · 5 comments

Comments

@yhyh0
Copy link

yhyh0 commented Feb 11, 2014

We are trying to re-throw exceptions as follows. But this way is not only ugly but also takes care of only the last continueWithBlock:.

What would you guys suggest on this?

[[task continueWithBlock:^id(BFTask *task) {
        //throws an exception
        return nil;
    }] continueWithBlock:^id(BFTask *task) {
        dispatch_async(dispatch_get_main_queue(), ^{
            if (task.exception) {
                @throw task.exception;
            }
        });
        return nil;
    }];
@bklimt
Copy link
Contributor

bklimt commented Feb 21, 2014

You can make this code slightly simpler by using a BFExecutor:

[[task continueWithBlock:^id(BFTask *task) {
    // throws an exception
    return nil;
}] continueWithExecutor:[BFExecutor mainThreadExecutor] withBlock:^id(BFTask *task) {
    if (task.exception) {
        @throw task.exception;
    }
    return nil;
}];

But I'm not sure exactly what problem you are trying to solve. Do you want to kill the app by forcing an unhandled exception?

@ide
Copy link
Contributor

ide commented Feb 25, 2014

I think it'd be good for unhandled exceptions to kill the app or at least produce an error message in the logs. Right now Bolts makes it harder to debug unanticipated exceptions since they're suppressed at the moment (at least when I tested @throwing an exception from an executor with a custom dispatch queue).

Throwing an idea out here: what if -[BFTask exception] logged whether the exception was accessed to get a rough idea of whether it was handled? If it hasn't been handled by the time the task is deallocated then we should rethrow or at least notify the debugger.

@robertjpayne
Copy link

It's quite annoying Bolts handles exceptions right now. Cocoa's philosophy is to use exceptions for fatal programmer errors. IE you've not checked the data type you're using etc… and errors for recoverable things such as the invalid permissions etc…

Bolts should have a way to completely disable exception handling or at least allow a way to log them off as it's impossible to raise them right now without passing them outside the task chain and then raising them.

@bklimt
Copy link
Contributor

bklimt commented Nov 25, 2014

You are right that it would be good to provide some mechanism to kill the app if an exception doesn't get handled by a continuation. Checking whether -[BFTask exception] gets called is interesting, but probably would have a lot of false positives. The other problem is that it's impossible to know if any given continuation is the last continuation that will be attached. In C# this is handled by the mechanism that rewrites await to use continuations, because they know that async void functions must rethrow, while async Task must not. So, if someone opens a pull request with a workable solution to this problem, we'll certainly consider it. But it's not obvious to us at this time exactly what that solution would be.

@bklimt bklimt closed this as completed Nov 25, 2014
@mrtj
Copy link

mrtj commented Mar 24, 2015

Sorry may I ask what is the rational behind closing an issue just because "it is not obvious to you what the solution would be"?
I must agree with the fellow developers above that Bolts masking all exceptions is a feature that makes maintaining a production level code very difficult.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants