| |
|
ExceptThis
Posted in reply to Ernesto Castellotti
| 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.
|