Support try/catch/finally Around an Abstract Function Which Might Throw

[sebmarkbage]

This is a follow up issue for #1142. In that implementation, we don't support catching an error from an abstract function call. This is not very high priority since I think this will be very rare and we can properly warn for this.

Imagine something like this in a pure context (e.g. in an additional function or React component):

var fn = __abstract('function', 'fn');
var x = 1;
try {
  fn();
  x = 2;
  fn();
  x = 3;
} catch (err) {
}
result = x;

Currently the code will assume that neither call will throw and therefore always result in result = 3.

To solve this I think we need calling an abstract function to be able to conditionally yield an abrupt completion. Yielding a joined completion.

The joinCondition for which branch to take isn't a direct value but whether the invocation worked or not.

I imagine we can have the call generator derive a value, a success flag and a thrown value. So the serialized code would be something like:

var $0_success = true;
var $0_thrown;
var $0;
try {
  $0 = fn();
} catch (thrown) {
  $0_success = false;
  $0_thrown = thrown;
}

The success flag value can be what the joinCondition uses. That way the joinCondition propagates properly when other values get joined. Subsequent emitted statements would get conditional on this value.

So the generated code end up something like this:

var $0_success = true;
try {
  fn();
} catch (_) {
  $0_success = false;
}

var $1_success = true;
if ($1_success) {
  try {
    fn();
  } catch (_) {
    $1_success = false;
  }
}

result = $0_success ? $1_success ? : 3 : 2 : 1;

[hermanventer]

This is pretty hard to do, not least because of that little foot note at the end: "We'd also need to handle the object passed to the catch."

A possible work around that already works, is to wrap the call to fn inside a concrete model function that checks the preconditions of fn and throws an appropriate exception if they fail. Then we can go back to regarding fn as pure and well behaved.

If fn uses exceptions to communicate rare conditions rather than precondition failures, then there is very little we can do statically. This is one of those situations where we throw up our hands and say "please change your code". In this instance you change your code by introducing a non throwing version of fn that returns status codes (or even exceptions) as return results.

[sebmarkbage]

I updated with a version where we also store the thrown value which is either undefined or the caught value. This effectively automatically turns this call into something that returns three values.

I'm not sure why this is different from if (condition) throw; which already works fine.

E.g. we can treat one of these calls effectively as:

var {success, exception, value} = callHelper(fn);

We can do that automatically.

In subsequent code:

if (!success) {
  throw exception;
}

This already works because conditional throws in conditional branches are already implemented.

[hermanventer]

A more direct way to fit in with current exception handling logic might be to provide a model function that defines an abstract function that returns not an AbstractValue, but a PossiblyNormalCompletion. The conditions we need for the PNC could well come from model variables that are set in a try catch that wraps the call.

[sebmarkbage]

I can actually model this helper in user space already. :)

(function () {
  function call(fn) {
    var template = {};
    __makePartial(template);
    __makeSimple(template);
    var res = __residual(template, function(fn) {
      var value;
      var exception;
      var success = true;
      try {
        value = fn();
      } catch (e) {
        exception = e;
        success = false;
      }
      return {value, exception, success};
    }, fn);
    if (!res.success) {
      throw res.exception;
    }
    return res.value;
  }
  
  var fn = __abstract('function', 'fn');
  
  var x = 1;
  try {
    call(fn);
    x = 2;
    call(fn);
    x = 3;
  } catch (err) {
  }
  result = x;

})();

It generates some pretty interesting code though.

EDIT: Even more interesting is that the serializer yields incorrect code.

[sebmarkbage]

Sorry, why is this closed? The original issue is not fixed and we might need it at some point later.