I'm using D to write an RSS reader.
As I understand it, the compiler does not guarantee correct
cleanup when an Error is thrown through a nothrow function.
Furthermore, it doesn't guarantee that an Error can be caught
(though it happens to allow it today).
Do I need to modify the compiler to ignore nothrow and treat all
throwables the same so it doesn't corrupt application state when
I recover from an Error? Fork vibe.d and every other library I
use to remove nothrow? I can't really justify that. My RSS reader
is a side project.
Do I accept that writing my code in D will result in a program
that will crash unrecoverably in cases where using C# would just
show a 503 and log an error to disk? That's a disservice to my
users.
Do I increase development time to make up for D's problems in
this area, pipe requests through a proxy that will convert
crashes to 503 errors, split things out into as many processes as
possible? At that point, I'll just use C#. It's less pleasant in
a wide variety of ways, but I'd save a lot of work and complexity.
And this practice is to make code marginally more efficient in
uncommon cases, because people are conflating "this is a problem
that a competent programmer should have been able to avoid"
(yeah, okay, I was incautious, we can move on) with "this
dependency of yours, probably the runtime, is in an invalid
state", and nothrow optimizations assume the latter only.
And it's exacerbated because bounds checking is seen as an option
to help with debugging instead of a safety feature to be used in
production. Because removing bounds checking is seen as a
sensible thing to do instead of a highly unsafe optimization.
It's exacerbated because Walter is in a mindset of writing
mission-critical applications where any detectable bug means you
need to restart the program. Honestly, if I were writing flight
control systems for Airbus, I could modify druntime to raise
SIGABRT or call exit(3) when you try to throw an Error. It would
be easy, and it would be worthwhile. If you really need cleanup,
atexit(3) is available.
