Comparing Exceptions and Errors

[Ola Fosheim Grøstad]

On Sunday, 5 June 2022 at 11:13:48 UTC, Adam D Ruppe wrote:
> On Sunday, 5 June 2022 at 10:38:44 UTC, Ola Fosheim Grøstad 
> wrote:
>> That is a workaround that makes other languages more 
>> attractive.
>
> It is what a lot of real world things do since it provides 
> additional layers of protection while still being pretty easy 
> to use.

Yes, it is not a bad solution in many cases. It is a classic 
solution for web servers, but web servers typically don't retain 
a variety of mutable state of many different types (a webserver 
can do well with just a shared memcache).


> My code did and still does simply catch Error and proceed. Most 
> Errors are completely harmless; RangeError, for example, is 
> thrown *before* the out-of-bounds write, meaning it prevented 
> the damage, not just notified you of it. It was fully 
> recoverable in practice before that silly Dec '17 dmd change, 
> and tbh still is after it in a lot of code.

Yes, this is pretty much how I write validators of input in 
Python web services. I don't care if the validator failed or if 
the input failed, in either case the input has to be stopped, but 
the service can continue. If there is a suspected logic failure, 
log and/or send notification to the developer, but for the end 
user it is good enough that they "for now" send some other input 
(e.g. avoiding some unicode letter or whatever).


> Or perhaps redefine RangeError into RangeException, 
> OutOfMemoryError as OutOfMemoryException, and such for the 
> other preventative cases and carry on with joy, productivity, 
> and correctness.

For a system level language such decisions ought to be in the 
hand of the developer so that he can write his own runtime. Maybe 
some kind of transformers so that libraries can produce Errors, 
but have them transformed to something else at boundaries.

If I want to write an actor-based runtime and do all my 
application code as 100% @safe actors that are fully «reliable», 
then that should be possible in a system level language.

The programmer's definition and evaluation of «reliability» in 
the context of a «casual game server» should carry more weight 
than some out-of-context-reasoning about «computer science» (it 
isn't actually).