Ages ago in C++ there was the hope of having the standard library give more error codes and use error values instead of full exceptions. Zig has some excellent innovations in that direction, any hope of that in D?

Edit: I think it was called "Herbception"s after Herb Sutter, and it really sounded like a good idea to me

▲ WalterBright 4 hours ago | parent | next [-]

It's been a while since I looked at Zig. I couldn't say anything intelligent about it without some study.

I used to be a big fan of C++ exceptions, but eventually soured on it for various reasons. Here's an article partially addressing it from a while back:

https://dlang.org/articles/exception-safe.html

▲ germandiago 2 hours ago | parent [-]

I think there is nothing better than exceptions + RAII for error handling since exceptions cannot be ignored by accident.

I would classify D's scope exit/failure/success as RAII actually, even if D uses a GC.

Sometimes you might not need exceptions and something like std::expected or optional is better.

In my case I use expected for some network APIs since I expect failures to happen out of my control aspart of the flow of my program, but I do not see why I would not use exceptions in many other situations, such as for non-ignorsble errors. I could think of a lack of disk space or some other fatal error thst is not under the control of the program.

If you forget to handle this, the error will cascade.

Also, exceptions do not make the signature of a function change (at least not in C++, Java checked exceptions is different). This means that the plasticity for adding errors at any depth of the call stack augments without bypassing any error silently.

All in all, I would say exceptions should be the main mechanism in normal circumstances and for expected errors you csn use error/result types.

▲ WalterBright 2 hours ago | parent | next [-]

> I would classify D's scope exit/failure/success as RAII actually, even if D uses a GC.

D's scope exit/failure/success is built on top of RAII and has nothing to do with the GC.

> I would say exceptions should be the main mechanism in normal circumstances and for expected errors you csn use error/result types.

Come to DConf (or watch the live stream) and I hope I can change your mind, or at least challenge your conclusions!

	▲	germandiago 10 minutes ago \| parent [-]
		> D's scope exit/failure/success is built on top of RAII and has nothing to do with the GC. What I meant here (I do not know the mechanism) is that I am aware that D has a GC. This means, correct me if I am wrong, that D does not use destructors (like C++) for scope exit/failure/success, though they are scoped mechanisms (RAII-like). > Come to DConf (or watch the live stream) I always follow D (even if I did not use it intensively). I have extremely high respect for you as a language designer and as a technician. Your knowledge is very refined, so I never take your opinions lightly. Probably one of the most knowledgeable persons in the industry for native language design. However, I am far and cannot attend, so I will definitely watch it. > or at least challenge your conclusions! No problem in challenging them. I am always open to do things better. This is just my practical experience as I implement stuff so far. I currently think exceptions seems like a good default mechanism (apparently at least) compared to alternatives. But I also think other mechanisms have their place and can/should be used even in the same program, just for different things. All mechanisms have trade-offs. I just talked about defaults from my POV for the kind of software I develop (mostly server-side, some client-side, and not embedded in the extremely constrained sense). ----------------------------- One question: I tried to use D several times in my career (20 years of C++ experience here, roughly). I found it a lot of fun. I like it better than more "modern languages". I like the plasticity D provides. But I am not sure how it would work if I want to do: `1. backend (server-side mainly, Linux is main platform, x86-64) 2. desktop + android and iOS (being mobile more important than desktop) 3. web assembly (even more important than mobile at this moment, could change). 4. backwards compatibility (heard complaints of versions breaking stuff frequently around). 5. interaction with C++.` I do like D a lot, but the problems I had before were more related to tooling (autocomplete, I use mainly Emacs but did not try for a few years) and toolchain maturity. It would be ready for all of the above? Also, very very handy would be to wrap C++ code and C code. I saw that D had an ongoing effort for C++ compatibility better than other languages, but I am afraid it could be half-broken. Even if it is, it is documented what works and what does not work? That would help a lot. Thanks.

▲ gregdaniels421 2 hours ago | parent | prev [-]

> I would classify D's scope exit/failure/success as RAII actually, even if D uses a GC.

It has better than that, but it is a bit clunky compared with C++(just use struct instead of class). You can have proper destructors, but if you have a container you need to be more careful than in C++.

In D exceptions are the default like in C++ and you have to opt out with nothrow or extern(C) or betterC.

Really try some D code in a bigger situation it is 90% good and almost worth using over C++, but if you can't have GC it is a huge pain, but better than C.

	▲	WalterBright 22 minutes ago \| parent [-]
		I've never understood why GC would be a huge pain. It makes some things a lot easier, like Compile Time Function Execution. Also, recently the GC implementation received a big modernization upgrade.

▲ wannabe44 an hour ago | parent | prev [-]

It was the throwing values proposal. Bjarne was not satisfied with the proposal because it didn't interact well with existing exceptions code.