On Wednesday, 11 July 2018 at 12:45:40 UTC, crimaniak wrote:
On Tuesday, 10 July 2018 at 22:59:08 UTC, Jonathan M Davis
This error handling policy makes D not applicable for creating
WEB applications and generally long-running services. I think
anyone who has worked in the enterprise sector will confirm
that any complex WEB service contains some number of errors
that were not detected during the tests. These errors are
detected randomly during operation. And the greatest
probability of their detection - during the peak traffic of the
site. Do you kill the whole application even in the case of
undisturbed memory, with one suspicion of a logical error? At
the peak of attendance? To prevent a potential catastrophe,
which could theoretically arise as a result of this error?
Congratulations! The catastrophe is already here.
And in the case of services, the strategy for responding to
errors must be exactly the opposite. The error should be
maximally localized, and the programmer should be able to
respond to any type of errors. The very nature of the work of
WEB applications contributes to this. As a rule, queries are
handled by short-lived tasks that work with thread-local
memory, and killing only the task that caused the error, with
the transfer of the exception to the calling task, would
radically improve the situation. And yes, RangeError shouldn't
be an Error.
Or aside from that strawman that RangeError shouldn't be an
I suspect that we're going to have to agree to disagree on
that one. ...
continuing to execute the program is risky by definition. ...
Sounds like you're describing the "Let it crash" philosophy of
The crucial point is whether you can depend on the error being
isolated, as in Erlang's lightweight processes. I guess D assumes