May 29, 2023
On Monday, 29 May 2023 at 21:18:23 UTC, Ernesto Castellotti wrote:
>
> 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)

Interesting observation. I presume you are talking about the syntax of exceptions that is triggering this drawback, because some newer languages have exceptions like Swift but isn't really exceptions underneath but more Rust like return values.

I must say that I in C++ often use return values rather than exceptions and even return enums. Now when you write this I haven't really reflected on this. I just wonder why do I do this? I think the answer is that they are simple and stupid.

Also I seen in a professional C++ environment that programmers tend to use exception incorrectly. For example they tend to catch all exceptions even if that isn't correct as they don't handle all exceptions. If a specific exception isn't handled, the program should exit.

This doesn't mean I'm against exceptions, I think exceptions are a very good error handling mechanism that allow inheritance thus expanding on existing error structures. Rust doesn't handle this well I think. Swift expanded upon the error handling of Rust and filled this gap.

The question remains, is it the syntax or the underlying error handling mechanism that prevents programmers from using exceptions correctly?

May 30, 2023
On 30/05/2023 9:18 AM, Ernesto Castellotti wrote:
> 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.

There are three categories that exceptions tend to fall into from what I've been able to tell.

1. Errors, show stoppers (use assert)
2. Genuinely exceptional, can stop program if not handled (use runtime exceptions)
3. Exceptional path ways, should not stop the program and needs to be handled close to throw (use value type exceptions)

A large portion of standard library stuff should really fall into the third, not the first or second IMO. Whereas runtime + threading should fall into first and second.
May 30, 2023

On Friday, 26 May 2023 at 12:42:41 UTC, FeepingCreature wrote:

>

On Thursday, 25 May 2023 at 15:36:38 UTC, Commander Zot wrote:

>

On Friday, 19 May 2023 at 15:58:25 UTC, ryuukk_ wrote:

>

For example:

  • exception handing: why use EH when you can have your function return 2 values (error and result)

oh god no. it leads to horrible code. just take a look at go.

Go is an unusually atrocious implementation. In a not terrible language, it just looks like foo()?.bar()?.baz.

now take the foo()?.bar()?.baz example, but change it to log which part failed. it only looks simple for the most basic case, the second you need to do rollbacks or really anything else this approach gets so much more complicated.

May 30, 2023
On Tuesday, 30 May 2023 at 05:41:14 UTC, Richard (Rikki) Andrew Cattermole wrote:
> On 30/05/2023 9:18 AM, Ernesto Castellotti wrote:
>> 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.
>
> There are three categories that exceptions tend to fall into from what I've been able to tell.
>
> 1. Errors, show stoppers (use assert)
> 2. Genuinely exceptional, can stop program if not handled (use runtime exceptions)
> 3. Exceptional path ways, should not stop the program and needs to be handled close to throw (use value type exceptions)
>
> A large portion of standard library stuff should really fall into the third, not the first or second IMO. Whereas runtime + threading should fall into first and second.

Exception are for one thing only: bailing out of some code because some problem occurred that cannot be handled locally. That's it, really.

The whole approach where one wonders if the error is recoverable or not or frequent or not and whatever is just the wrong way to think about it. The right way is the opposite way around: if you find yourself frequently throwing, then your API is likely wrong, because you find yourself not being able to handle something locally that happens all the time.
May 30, 2023
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?
May 31, 2023

On Tuesday, 30 May 2023 at 09:13:03 UTC, Commander Zot wrote:

>

now take the foo()?.bar()?.baz example, but change it to log which part failed. it only looks simple for the most basic case, the second you need to do rollbacks or really anything else this approach gets so much more complicated.

foo()
  .case(Error: return Error.failedAt(__RANGE__))
  .bar()
  .case(Error: return Error.failedAt(__RANGE__))
  .baz;

And sure that looks verbose, but the moment I needed more than a few of them I'd just add a macro for it.

May 31, 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.

June 20
On Sunday, 28 May 2023 at 07:06:54 UTC, Walter Bright wrote:

> Autodecoding is a feature of the library, not the language. We've all agreed that Phobos v2 will not have it.

Sorry I only check in on the forums sporadically so not sure if this is talked about somewhere else. Can you elaborate what "phobos v2" entails?
June 20
On Tuesday, 20 June 2023 at 04:05:49 UTC, A moo person wrote:
> On Sunday, 28 May 2023 at 07:06:54 UTC, Walter Bright wrote:
>
>> Autodecoding is a feature of the library, not the language. We've all agreed that Phobos v2 will not have it.
>
> Sorry I only check in on the forums sporadically so not sure if this is talked about somewhere else. Can you elaborate what "phobos v2" entails?

The idea of development newer versions of std.
https://forum.dlang.org/thread/slktaa$vnl$1@digitalmars.com?page=1
1 2 3 4 5 6 7 8
Next ›   Last »