3 ms·

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

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 2mo ago
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 https://dlang.org/articles/exception-safe.html
- germandiago 2mo ago
  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.
  - gregdaniels421 2mo ago
    > 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 2mo ago
      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.
  - WalterBright 2mo ago
    > 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 2mo ago
      > 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.
  - nicoburns 2mo ago
    The worst thing about exceptions is that you can't tell from the type signature of a function whether it might throw one. So you have to hope it's documented, guess at whether try-catch is necessary, or reading through the entire call stack. I personally much prefer Rust style Result which also can't be ignored, and puts fallibili5y in the function signature.
    - michaelt 2mo ago
      > The worst thing about exceptions is that you can't tell from the type signature of a function whether it might throw one. In Java exceptions can be part of a method's declared type information, so handling is checked at compile time and IDEs can display the info. Unfortunately certain Java missteps made this design unpopular these days. For example, for many years new String(bytes, "UTF-8"); made it mandatory to catch a UnsupportedEncodingException despite the language spec guaranteeing UTF-8 would be available. A later version of Java addressed it, but still...
      - vips7L 2mo ago
        Java's problem with checked exceptions is that they didn't add them fully to the type system (the lambda problem), and they never added any syntax sugar to make them easier to deal with. I really love checked exceptions and wish we could get some improvements.
    - mgaunard 2mo ago
      Any function can throw an exception unless it is marked noexcept. Your code shouldn't need to make assumption about whether exception are being thrown or not. Your mistake is thinking that a function potentially throwing means you need to catch it.
    - germandiago 2mo ago
      Or you can assume exceptions can be thrown and capture and log coming from a base class in a centralized place (and probably refine incrementally what to do with each group without dirtying all the logic inside the functions themselves). For Rust result in C++ you have optional and expected. But they have their own problems, like rewriting function signatures all the way up the stack if you notice an error was possible when adding code.
wannabe44 2mo ago
It was the throwing values proposal. Bjarne was not satisfied with the proposal because it didn't interact well with existing exceptions code.
- jeffreygoesto 2mo ago
  I loved the comparison of HerbCeptions with expected in https://m.youtube.com/watch?v=GC4cp4U2f2E https://m.youtube.com/watch?v=GC4cp4U2f2E, a very insightful easy of looking at that topic and really entertaining, too.
pjmlp 2mo ago
Value type exceptions went nowhere, because that was yet another paper that was never turned into a proper proposal. Additionally, Khalil Estell has made an excellent work proving that the way exceptions are currently implemented is not optimal and there is plenty of room for improvement, when someone cares about their implementation. "Cutting C++ Exception Time by +90%? - Khalil Estell - CppCon 2025" https://www.youtube.com/watch?v=wNPfs8aQ4oo https://www.youtube.com/watch?v=wNPfs8aQ4oo
- alphaglosined 2mo ago
  I created the D version of the value type exceptions proposal. In the end, it was DOA due to compiler architecture, so that was the end of that beautiful design. I've had to accept result types is about as good as its going to get, all that is missing to make them nice is unwrapping support in if statements. Which I too have a proposal for and implemented it. But alas politics.
  - vips7L 2mo ago
    You might not see this since I'm rather late. What is a value type exception? Is it one that doesn't collect a stack trace? Or doesn't unwind in the usual way or something?

WalterBright 2mo ago

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 https://dlang.org/articles/exception-safe.html

germandiago 2mo ago
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.
- gregdaniels421 2mo ago
  > 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 2mo ago
    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.
- WalterBright 2mo ago
  > 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 2mo ago
    > 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.
- nicoburns 2mo ago
  The worst thing about exceptions is that you can't tell from the type signature of a function whether it might throw one. So you have to hope it's documented, guess at whether try-catch is necessary, or reading through the entire call stack. I personally much prefer Rust style Result which also can't be ignored, and puts fallibili5y in the function signature.
  - michaelt 2mo ago
    > The worst thing about exceptions is that you can't tell from the type signature of a function whether it might throw one. In Java exceptions can be part of a method's declared type information, so handling is checked at compile time and IDEs can display the info. Unfortunately certain Java missteps made this design unpopular these days. For example, for many years new String(bytes, "UTF-8"); made it mandatory to catch a UnsupportedEncodingException despite the language spec guaranteeing UTF-8 would be available. A later version of Java addressed it, but still...
    - vips7L 2mo ago
      Java's problem with checked exceptions is that they didn't add them fully to the type system (the lambda problem), and they never added any syntax sugar to make them easier to deal with. I really love checked exceptions and wish we could get some improvements.
  - mgaunard 2mo ago
    Any function can throw an exception unless it is marked noexcept. Your code shouldn't need to make assumption about whether exception are being thrown or not. Your mistake is thinking that a function potentially throwing means you need to catch it.
  - germandiago 2mo ago
    Or you can assume exceptions can be thrown and capture and log coming from a base class in a centralized place (and probably refine incrementally what to do with each group without dirtying all the logic inside the functions themselves). For Rust result in C++ you have optional and expected. But they have their own problems, like rewriting function signatures all the way up the stack if you notice an error was possible when adding code.

wannabe44 2mo ago

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

jeffreygoesto 2mo ago
I loved the comparison of HerbCeptions with expected in https://m.youtube.com/watch?v=GC4cp4U2f2E https://m.youtube.com/watch?v=GC4cp4U2f2E, a very insightful easy of looking at that topic and really entertaining, too.

pjmlp 2mo ago

Value type exceptions went nowhere, because that was yet another paper that was never turned into a proper proposal. Additionally, Khalil Estell has made an excellent work proving that the way exceptions are currently implemented is not optimal and there is plenty of room for improvement, when someone cares about their implementation. "Cutting C++ Exception Time by +90%? - Khalil Estell - CppCon 2025" https://www.youtube.com/watch?v=wNPfs8aQ4oo https://www.youtube.com/watch?v=wNPfs8aQ4oo

alphaglosined 2mo ago
I created the D version of the value type exceptions proposal. In the end, it was DOA due to compiler architecture, so that was the end of that beautiful design. I've had to accept result types is about as good as its going to get, all that is missing to make them nice is unwrapping support in if statements. Which I too have a proposal for and implemented it. But alas politics.
- vips7L 2mo ago
  You might not see this since I'm rather late. What is a value type exception? Is it one that doesn't collect a stack trace? Or doesn't unwind in the usual way or something?