Feedback from the Gripes and Wishes Campaign
ExceptThis
ExceptThis at gmail.com
Wed May 31 09:10:00 UTC 2023
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.
More information about the Digitalmars-d
mailing list