> Your web server example is uncompelling, because a panic-based abort is not the only thing that can distress your system.
You seem to be saying that it wouldn't catch 100% of the problems, so catching only 80% is not that useful.
I see that as uncompelling. 80% helps a lot!
> you need the code that will produce that to run on a different computer
Problem is, we're using C, C++ and Rust, because latency and performance matters. Otherwise we'd be using Go or Java.
So in order to do what you're proposing, we'd have to do an outbound call on every link of a large filter/processing chain, serializing, transferring, and parsing the whole request data at each recoverable step.
What I’m describing about producing 500s from a different machine is standard practice at scale, part of load balancers. And at small scale, it’s still pretty standard practice to do that from at least a different process, part of reverse proxying.
You seem to be saying that it wouldn't catch 100% of the problems, so catching only 80% is not that useful.
I see that as uncompelling. 80% helps a lot!
> you need the code that will produce that to run on a different computer
Problem is, we're using C, C++ and Rust, because latency and performance matters. Otherwise we'd be using Go or Java.
So in order to do what you're proposing, we'd have to do an outbound call on every link of a large filter/processing chain, serializing, transferring, and parsing the whole request data at each recoverable step.