Re: The latest attempt to fix sync/async error handling: implicit ejector arguments.

[bcc friam: please send all further discussion to e-lang principally]

On Oct 14, 2014, at 4:20, Daira Hopwood <davidsarah.hopwood-gM/[email protected]> wrote:
On 11/10/14 04:21, Kevin Reid wrote:
> [...]
>> The original form of promise error handling was that when a message was
>> received and delivered to a near (local) object, the local call operation
>> would be effectively wrapped in a try-catch, something like:
>>  def deliver(resolver, target, argument) {
>>    try {
>>      resolver.resolve(target(argument))    # obviously a more general
>>                                            # call, actually
>>    } catch aProblem {
>>      resolver.smash(aProblem)
>>    }
>>  }
>> 
>> However, sealed exceptions says that aProblem is one of those uninformative
>> sealed objects, so this mechanism doesn't work for _handled_ errors any more.
> 
> I think this is slightly misanalysing the problem.
> 
> Leakage of secrets from error descriptions is an issue whether the error is
> handled synchronously or asynchronously.
> 
> The problem is therefore not with the above try/catch. It's with the fact
> that the caller can't specify which authority is needed to unseal the error
> description in the async case.

[bcc friam: please send all further discussion to e-lang principally]

I am not proposing an error-_handling_ mechanism which involves _sealers_. The sealed exceptions in the sealed-exceptions-scheme are precisely those which are _not available to any application code_ (only from the role of debuggers), because they have been thrown. I do not wish to try to rescue any information from them, because by being thrown they have participated in a dynamic-scope mechanism.

Instead, I am trying to establish a non-dynamically-scoped -- capability-structured -- path by which the errors may be communicated. If we get this right, no amplification is needed and therefore no sealers, in both the sync and async cases.

> If the caller could specify this, then it would be possible to write asynchronous
> error handling code exactly analogous to synchronous use of escapes. The error
> description would still be implicitly passed to resolver.smash, but it could
> only be unsealed (and tested for a particular error) by using [the unsealer
> corresponding to] the sealer
> passed to the original call. The code in the callee would be the same.

I see what you are proposing. It is indeed very similar to my scheme in what it requires of the programmer.

However, I don't like it aesthetically, because I would prefer to eliminate dynamic-scoped-value-passing entirely from the language, and in particular I am concerned that it could interact with other features to create a communication path which is, if not technically a capability violation, at least surprising. Because I don't like it, I'm going to throw some mud and we can see what sticks:

It is _not_ equivalent to ejectors, because ejections cannot be caught (though they can be aborted via finally) but throws can. (This is a valuable property of ejections -- it eliminates one of the arguments against using exceptions for flow control.) Thus code which e.g. wraps an entire error-prone block (that happens to contain calls to FAIL) with a try-catch sees different behavior in the two cases.

Here's an example of a bad habit it could enable: a program which _one_ exception-sealer, then using it for all of its eventual sends. This would allow the program to exhibit "sibling amplification" between them and end up attributing failures peculiarly if the callee is sufficiently twisty -- and this is also unlike ejectors.

Finally, if this is a good way to handle eventual errors, why not use it for immediate errors? That is, pass throw-sealers around where we currently use ejectors. (Maybe the answer is that we should! I'd be surprised.)

[bcc friam: please send all further discussion to e-lang principally]

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>