Comparing Exceptions and Errors

[Ola Fosheim Grøstad]

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!