Raymond Chen's take on so-called zero cost exceptions (page 2)

On Monday, 28 February 2022 at 20:33:17 UTC, Walter Bright wrote: > > This is what I've been saying. Yeah, well, you can switch gears more quickly by having paddles shifters on the steering wheel. But so many of us have no problem with the location of the gear selector that we're all familiar with. I feel like my mechanic is telling me I should move to paddle shifters, cause then I can change more quickly. But what's it gonna cost me? And can I both, in case I don't like (or can't get used to) the paddle shifters. So the point being made in the article, is kinda... pointless.. really. i.e. It's the other questions that immediately arise that need to be answered (or even asked would be a nice start).

On Tuesday, 1 March 2022 at 06:57:26 UTC, forkit wrote: > On Monday, 28 February 2022 at 20:33:17 UTC, Walter Bright wrote: >> >> This is what I've been saying. > > Yeah, well, you can switch gears more quickly by having paddles shifters on the steering wheel. > > But so many of us have no problem with the location of the gear selector that we're all familiar with. > > I feel like my mechanic is telling me I should move to paddle shifters, cause then I can change more quickly. > > But what's it gonna cost me? And can I both, in case I don't like (or can't get used to) the paddle shifters. > > So the point being made in the article, is kinda... pointless.. really. > > i.e. It's the other questions that immediately arise that need to be answered (or even asked would be a nice start). D is in a position where it can, and should, do what ever it wants to do, that gives us an advantage over the competition, Nim for example didn't wait what ever someone says on a forum to implement RC, Zig didn't wait for anybody to do the way they do error handling, and soon compile time error for unused things despite many people against it [0] Nobody should wait for you to become comfortable to improve things People attach to a language for its vision, not because it sticks to whatever he though was good 20 years ago Someone mentioned Swift, they didn't wait for anybody to implement the Actor model at language level, same for adding language features to make SwiftUI play nice We try, we make mistakes, we learn, we change, we teach, we evolve [0] https://github.com/ziglang/zig/issues/335

On Tuesday, 1 March 2022 at 07:08:24 UTC, meta wrote: > ... Nobody should wait for you to become comfortable to improve things >.... Lucky you are not my mechanic. Otherwise, you would have just lost a customer ;-)

On Tuesday, 1 March 2022 at 06:57:26 UTC, forkit wrote: > On Monday, 28 February 2022 at 20:33:17 UTC, Walter Bright We need to refocus on why exception handling was introduced, and not just on it's 'cost'. Only then do we have a subject worthy of discussion: "..exception handling was introduced to solve some of these problems" - CppCon 2019: Ben Saks “Back to Basics: Exception Handling and Exception Safety” https://www.youtube.com/watch?v=W6jZKibuJpU

On Tuesday, 1 March 2022 at 07:18:29 UTC, forkit wrote: > On Tuesday, 1 March 2022 at 07:08:24 UTC, meta wrote: >> ... Nobody should wait for you to become comfortable to improve things >>.... > > Lucky you are not my mechanic. Otherwise, you would have just lost a customer ;-) It's ok, customers aren't eternal, we need to refresh the pool of developers and attract new souls, whom find exception handling to be a bad idea ;) However we also need to retain existing ones It's hard to balance the two, but the former is important, it makes it so the product last when the creator is no longer here.. it's life That's how my company still makes that mobile game as a service, the same game, since the beginning of iPhones, still kicking strong with new users, the game is totally different today than what it was in the past.. totally worth it

On Tuesday, 1 March 2022 at 07:50:27 UTC, forkit wrote: > > We need to refocus on why exception handling was introduced, and not just on it's 'cost'. > Yes, features always comes at a cost. Bounds checking costs CPU cycles but most people are OK with the extra cost. Another thing that I don't understand. Exceptions have been around for a long time. In the 90s and beginning of 2000s there wasn't much talk about the cost of exceptions. 20 years later and computers are a magnitude faster, suddenly exceptions are too expensive.

On Monday, 28 February 2022 at 23:01:46 UTC, Guillaume Piolat wrote:

Performance is imo a false concern here since 1. either code that should be fast is devoid of eror handling in the first place 2. correctness of whole codebases is at stake 3. you can always make a correct program faster, but there will be noone to realize the incorrect program is incorrect.

Yes, that is my experience as well. You try to avoid the need for error-handling and if errors can arise you delay the handling of it.

Examples:

In a parser you can build a log, then check the log after parsing.
In a raytracer you can tag a pixel as failed and check it at the bottom level and retry with better solvers (or a slightly different angle or whatever).

Complex error situations usually are most relevant in I/O, but in order to get the highest performance I/O you have to special case all the I/O code to the platform and use whatever response mechanism the platform provides. If you are creating a library abstraction you won't get optimal performance anyway and exceptions tend to have smaller impact than other sources for latency.

I probably would not want to use unchecked exceptions for embedded, but that is a different discussion.

March 01, 2022

Re: Raymond Chen's take on so-called zero cost exceptions

Posted by meta
in reply to IGotD-

Permalink

meta

Posted in reply to IGotD-

Permalink

On Tuesday, 1 March 2022 at 10:27:10 UTC, IGotD- wrote:

On Tuesday, 1 March 2022 at 07:50:27 UTC, forkit wrote:

We need to refocus on why exception handling was introduced, and not just on it's 'cost'.

Yes, features always comes at a cost. Bounds checking costs CPU cycles but most people are OK with the extra cost.

Another thing that I don't understand. Exceptions have been around for a long time. In the 90s and beginning of 2000s there wasn't much talk about the cost of exceptions. 20 years later and computers are a magnitude faster, suddenly exceptions are too expensive.

You can disable bounds checking, and it's not the same, you know before hand the cost and how it affects your program as a whole, which is not the case for exception handling

It also is a way to design your software, proper error handling is verbose but leads to better and more portable results, syntax is simpler, easier to read and to follow

With exception handling, you never know what will throw, or if something was already catched, or if you catch or cast the wrong Base type, etc (thanks OOP for yet another level of complexity btw)

Error codes are just better in every aspects, scales from embedded to what ever complex solution you have

They are even better when the language understands what is an 'error' at the semantic level

Again, error handling is better in every aspects

Also my use cases for D are system level softwares (graphics/audio engine, low level networking, automation)

I should mention that I'm not asking for enforcing error handling to everyone, I just want to make sure I can live and keep programming by not having to use exceptions at all :)

Also It is a personal opinion, you can't make me use them if I consider it to be a bad practice, even if some people disagree with that statement

Forums