Built-in actors abort versus errors

[Stebalien]

• In go actors, we panic (abort) with an exit code on error.
• In rust actors, we bubble an error all the way to the caller.

We should abort in rust actors as well:

• It's easier to say we exit with code X on error E, because nothing can intercept/downcast/etc. the error.
• It's faster (we exit immediately) and helps the compiler optimize for the non-error path.

[raulk]

In the Forest actors there was no hard system boundary between actors and the runtime, that’s why they return/propagate up the stack.

In the post-FVM world, the trampoline shims the no-boundary world with the boundary world by recognising the error after its been propagated, and signalling the interruption across the boundary.

IMO, the key behaviour we want to bring home is that the actor emitting an error should interrupt execution immediately.

Go achieves this through the usage of panics. WASM can achieve this by invoking a host function that traps. I'm all onboard with the latter model.

[Stebalien]

Sounds good to me.

In the Forest actors there was no hard system boundary between actors and the runtime, that’s why they return/propagate up the stack.

Yes and no. It would have been possible to create that boundary with https://doc.rust-lang.org/std/panic/fn.catch_unwind.html.

[jennijuju]

this can be a post network v16 thing - whoever has time, it would be nice to. pick this up

[anorth]

This would make matching the Go actors behaviour much easier to verify for nv16.

[anorth]

I agree with the "should" here, but are we really going to do it? I don't think we'll ever get to it, and the thing we have now works (module #52).

[Stebalien]

Not in the near term, but I expect this is something new contributors could chip away at.

[anorth]

I propose closing this issue as something we're not going to action. Any objections?

[Stebalien]

Not really. I still think this is something we should explore (maybe in a new sdk) but it's not really actionable as-is.