Feedback from the Gripes and Wishes Campaign

[ExceptThis]

On Tuesday, 30 May 2023 at 19:45:27 UTC, Ernesto Castellotti 
wrote:
> On Monday, 29 May 2023 at 21:18:23 UTC, Ernesto Castellotti 
> wrote:
>> On Monday, 29 May 2023 at 20:57:22 UTC, H. S. Teoh wrote:
>>> On Mon, May 29, 2023 at 08:21:37PM +0000, Ernesto Castellotti 
>>> via Digitalmars-d wrote:
>>>> On Monday, 29 May 2023 at 18:40:52 UTC, Paul Backus wrote:
>>>> > revisiting the use of exceptions in the standard library
>>>> 
>>>> As far as I'm concerned, they really shouldn't be used. I 
>>>> think exceptions are one of the worst features of C++, Java 
>>>> and D etc
>>>
>>> Care to elaborate why?
>>>
>>>
>>> T
>>
>> Mainly because exceptions are often used for errors that 
>> aren't really exceptional", I often found myself having to 
>> handle exceptions (mostly in Java and C++) that really didn't 
>> give a damn and just abort the program.
>>
>> I have rarely seen exceptions handled well by programmers 
>> other than in C++ code done by really experienced programmers, 
>> I much prefer error handling like Rust and Go ie with 
>> multi-value returns, in my experience I have always found this 
>> technique leads to much better error handling than using 
>> exceptions. (https://go.dev/doc/faq#exceptions, 
>> https://go.dev/blog/error-handling-and-go, 
>> https://doc.rust-lang.org/book/ch09-00-error-handling.html)
>
> Still about the exceptions, what is the reason that motivates 
> the existence of this 
> https://dlang.org/library/object/error.html
>
> If they are unrecoverable errors how could I handle them as 
> exceptions? Print an error message and close the program? But 
> then why am I using exceptions anyway to do this?

Sadly, confusing terminology is **always** at play when 
discussing these things...

First we all need to agree that:

error != exception
Error != Exception

In my mind, a program can only produce an error, not an exception.

The word exception should only come into play when talking about 
how to handle an error - i.e see below.


(1) In essence, all programs have the potential to produce errors.

(2) These errors are either things you expect might occur, or 
things you might not expect to occur.

(3) These errors can be further classified as either being:
- errors that probably should be handled
- errors that probably should not be handled.

Often arguments over what should or shouldn't be handled are 
pointless, since it depends completely on the nature of the 
program and its intended use and audience.

For example, I would not handle an out of memory error in my 
programs. I don't expect it to occur, and if it should, I do not 
want my program to have to deal with it. Other programs may well 
need to handle it.

Whereas, I would always Try.. to handle a 'Cant save this file' 
error.

Errors that probably should be handled, should throw such errors 
as an Exception object, to be handled.

Errors that probably should not be handled, should throw such 
errors as an Error object, not to be handled.

see object.d

class Throwable : Object - The base class of all thrown objects.

class Exception : Throwable - The base class of all errors that 
are safe to catch and handle

class Error : Throwable - The base class of all unrecoverable 
runtime errors.

The great advantage of Exceptions (vs the old C like return 
values) are that Exceptions provide a robust, structured and 
uniform way in which you can handle these kinds of program errors.