How to re-throw exceptions? about bolts-objc HOT 5 CLOSED

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?

from bolts-objc.

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.

from bolts-objc.

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.

from bolts-objc.

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.

from bolts-objc.

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.

from bolts-objc.