4 ms·

The scenario is not invented per se, it’s something that really happens sometimes. Maybe the systems you interact with never return malformed data more than a f

by jolux 5y ago

The scenario is not invented per se, it’s something that really happens sometimes. Maybe the systems you interact with never return malformed data more than a few times, but the ones I work with do. Throwing an exception on a deserialization failure in order to crash your process just seems like punting on your retry logic to me.

keathley 5y ago
Sorry, "invent" had the wrong connotations there. I just meant that there are scenarios where crashing wouldn't be acceptable. And in that case, sure, you should prefer to handle the error directly. But, allowing the process to crash doesn't punt retry logic at all. For instance, in the work scheduler example, the work scheduler would detect that a worker had crashed and would back off appropriately. This allows you to write your worker code in a way that avoids error handling while still managing faults.
- jolux 5y ago
  The work scheduler example involves writing a work scheduler, though :). The logic is going to go somewhere, is what I’m saying.
lmm 5y ago
Right, but often you should punt your retry logic. You already need to handle process crash at high level, so you already want some kind of restart/backoff in your supervisor. Unless there's something specific that you want to do differently for this particular kind of failure, having separate retry/backoff logic for each kind of failure is just clutter.
- jolux 5y ago
  You should definitely handle the crash at a high level, but that’s not the same as punting on it!
  - lmm 5y ago
    Not putting any explicit handling for failed requests and instead allowing the current process to crash, knowing that the supervisor's handling will do the right thing in that case, isn't that punting it? I'm not fluent in American but doesn't punting pretty much mean kicking something far away?
    - jolux 5y ago
      It means giving up, more or less. The default handling that a supervisor provides is probably not sufficient for a looping failure, was the point.

by jolux 5y ago

keathley 5y ago

Sorry, "invent" had the wrong connotations there. I just meant that there are scenarios where crashing wouldn't be acceptable. And in that case, sure, you should prefer to handle the error directly. But, allowing the process to crash doesn't punt retry logic at all. For instance, in the work scheduler example, the work scheduler would detect that a worker had crashed and would back off appropriately. This allows you to write your worker code in a way that avoids error handling while still managing faults.

jolux 5y ago
The work scheduler example involves writing a work scheduler, though :). The logic is going to go somewhere, is what I’m saying.

lmm 5y ago

Right, but often you should punt your retry logic. You already need to handle process crash at high level, so you already want some kind of restart/backoff in your supervisor. Unless there's something specific that you want to do differently for this particular kind of failure, having separate retry/backoff logic for each kind of failure is just clutter.

jolux 5y ago
You should definitely handle the crash at a high level, but that’s not the same as punting on it!
- lmm 5y ago
  Not putting any explicit handling for failed requests and instead allowing the current process to crash, knowing that the supervisor's handling will do the right thing in that case, isn't that punting it? I'm not fluent in American but doesn't punting pretty much mean kicking something far away?
  - jolux 5y ago
    It means giving up, more or less. The default handling that a supervisor provides is probably not sufficient for a looping failure, was the point.