3 ms·

I agree that OP only reduced his statement to a subset of the things that can go wrong. But the error handling mechanism is uniform across any errors that can b

I agree that OP only reduced his statement to a subset of the things that can go wrong. But the error handling mechanism is uniform across any errors that can be caused.

JonChesterfield 3y ago
Therefore the function has its own failure modes and also a set of extra ones from the execution framework, folded into an exception hierarchy?
- IshKebab 3y ago
  That is how exceptions always work in these sort of languages. I think it's one of the reasons exceptions suck as an error mechanism (checked exceptions are the "answer" but hardly anyone uses those - so few in C++ that they were removed from the language!), but it isn't a new problem introduced by this framework. In any case Typescript doesn't have checked exceptions so you're pretty much stuck with "any error can happen anywhere" in Typescript whether you use this framework or not.
pjmlp 3y ago
So how does that map to an operation that was done with success, but the reply lost?
- lunarcave 3y ago
  If the reply is lost, then the caller eventually times out, which causes an exception. There's a bit of nuance here about where the reply got lost. 1. Between control-plane and the callee 2. Between control-plane and the caller But broadly, unless idempotency[1] is requested, it can re-run the function. [1] https://docs.differential.dev/advanced/idempotency/ https://docs.differential.dev/advanced/idempotency/
  - pjmlp 3y ago
    Yeah, but that is the thing, in many cases re-runing is not an option, as most services don't guarantee idempotenty.
    - lunarcave 3y ago
      We might be talking over each other here. But your earlier point was about exceptions, and I've tried to answer it in that context. Yes, most services do not guarantee idempotency. But your service could if you use the idempotency utility that Differential supplies. If you don't care about idempotence in your service calls, you could let it re-run. I believe most service calls don't care about idempotence. - Reading stuff from a database? It can safely be re-run. - PUT stuff to an external source, all good. - Creating a new resource? Well, the failure mode is no better than what your system would do with an equivalent service call via another mechanism. So you need to handle it / write it in a way that ensures idempotence / be ready not to care. - Creating an order, or charging a credit card? Yes - that needs to be handled and can be handled with the idempotence helper.

I agree that OP only reduced his statement to a subset of the things that can go wrong. But the error handling mechanism is uniform across any errors that can be caused.

JonChesterfield 3y ago

Therefore the function has its own failure modes and also a set of extra ones from the execution framework, folded into an exception hierarchy?

IshKebab 3y ago
That is how exceptions always work in these sort of languages. I think it's one of the reasons exceptions suck as an error mechanism (checked exceptions are the "answer" but hardly anyone uses those - so few in C++ that they were removed from the language!), but it isn't a new problem introduced by this framework. In any case Typescript doesn't have checked exceptions so you're pretty much stuck with "any error can happen anywhere" in Typescript whether you use this framework or not.

pjmlp 3y ago

So how does that map to an operation that was done with success, but the reply lost?

lunarcave 3y ago
If the reply is lost, then the caller eventually times out, which causes an exception. There's a bit of nuance here about where the reply got lost. 1. Between control-plane and the callee 2. Between control-plane and the caller But broadly, unless idempotency[1] is requested, it can re-run the function. [1] https://docs.differential.dev/advanced/idempotency/ https://docs.differential.dev/advanced/idempotency/
- pjmlp 3y ago
  Yeah, but that is the thing, in many cases re-runing is not an option, as most services don't guarantee idempotenty.
  - lunarcave 3y ago
    We might be talking over each other here. But your earlier point was about exceptions, and I've tried to answer it in that context. Yes, most services do not guarantee idempotency. But your service could if you use the idempotency utility that Differential supplies. If you don't care about idempotence in your service calls, you could let it re-run. I believe most service calls don't care about idempotence. - Reading stuff from a database? It can safely be re-run. - PUT stuff to an external source, all good. - Creating a new resource? Well, the failure mode is no better than what your system would do with an equivalent service call via another mechanism. So you need to handle it / write it in a way that ensures idempotence / be ready not to care. - Creating an order, or charging a credit card? Yes - that needs to be handled and can be handled with the idempotence helper.