Re: Comparing Exceptions and Errors

[Ola Fosheim Grøstad via Digitalmars-d-learn]

On Saturday, 4 June 2022 at 01:17:28 UTC, Steven Schveighoffer 
wrote:
I've thought in the past that throwing an error really should 
not throw, but log the error (including the call stack), and 
then exit without even attempting to unwind the stack. But code 
at least expects an attempt to throw the Error up the stack, so 
code that is expecting to catch it would break.

This is too harsh for a service that is read-only, meaning a 
service that only read from a database and never writes to it. 
All running threads have to be given a chance to exit gracefully, 
at the very minimum.

What is the source for these errors anyway? A filesystem not 
responding? A crashed device driver? A race condition? A 
deadlock? Starvation? Many sources for errors can be recovered 
from by rescheduling in a different order at a different time.

What I'd like to see is a fault tolerant 100% @safe actor pattern 
with local per-actor GC. By fault tolerant I mean that the actor 
is killed and then a new actor is rescheduled (could be an 
alternative "reference" implementation or the same after a time 
delay).

Also, what it is the purpose of @safe if you have to kill all 
threads? Such rigidity will just make Go look all the more 
attractive for service providers!