37
I Don't Use Exceptions in C++ Anymore (thelig.ht)
submitted 2 years ago by to c/programming@programming.dev
18 comments fedilink hide all child comments
 

Using exceptions in C++ desktop and server applications overall made sense to me. As I expanded my usage of C++ into other domains, specifically embedded domains, I began to experience more compelling reasons not to use exceptions first-hand...

From lobste.rs

all 18 comments

sorted by: hot top controversial new old
[–] 17 points 2 years ago* (1 child)

It's a shame that sum type support is still so lacking in C++. Proper Result types (ala Haskell or Rust) are generally much nicer to deal with, especially in embedded contexts.

As is, there's only std::expected (which can and will blow up in your face if you forget to check has_value) and std::variant, which I have heard nothing but complaints about.

  • permalink
  • fedilink
  • source
  • hideshow 2 child comments
    •
  • [–] 2 points 2 years ago (1 child)

    It’s a shame that sum type support is still so lacking in C++. Proper Result types (ala Haskell or Rust) are generally much nicer to deal with, especially in embedded contexts.

    I don't think this is a lack of support in C++. There are already a few C++ libraries that implement Either and Result monads. It would be nice if those were supported in the C++ stand library, but that does not stop anyone from adopting them.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 10 points 2 years ago* (2 children)

    I would consider language support essential for "good" sum types. AFAIK, stuff like exhaustive pattern matching can't be accomplished by a library. Perhaps you could do some cursed stuff with compiler plugins, however.

    (There was a library that implemented non-exhaustive pattern matching that eventually morphed into an ISO C++ proposal... so we won't see it until 2030 at the earliest /hj)

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 4 points 2 years ago (1 child)

    At a library level, couldn't you have an opaque sum type where the only thing you can do with it is call a match method that requires a function pointer for each possible variant of the sum type? It'd be pretty cursed to use but at least it wouldn't require compiler plugins.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] -1 points 2 years ago (2 children)

    I think that pattern matching and sum types are orthogonal to monads, and aren't really relevant when discussing monads as alternatives to exceptions. C++ didn't required any of those to add std::optional or std::variant, and those are already used as result monads.

    Supporting Result and Either monads in the standard would be nice, but again this does not stop anyone from adopting one of the many libraries that already provide those.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 3 points 2 years ago (1 child)

    Well, if you create result types without monads, you get go.

    I would say it's completely essential, but you can do with some limited implementation of them.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 2 years ago (1 child)

    You seem to be ignoring the benefits of compiler support as mentioned in the comment above.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 2 years ago* (1 child)

    compiler support

    That remark was on sum types, not monads. You do not need "compiler support" to have Result or neither monads in C++. There are already plenty of libraries that implement those. I use them in some of my projects. No compiler support needed.

    As I said, sum types are not required for Return or Either monads. At best, they are convenient.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 2 years ago (1 child)

    The original claim wasn't that you can't implement monads in C++, it was that compiler support is needed for "good" sum types. Unless I'm misreading, you brought monads into it. And they're not totally orthogonal: sum types are a very good way to implement monads.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 2 years ago* (1 child)

    Unless I’m misreading, you brought monads into it.

    You're misreading it. What do you think a 'Result' type is?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 2 years ago (1 child)

    Well, in Rust, it's a sum-type, with functions that also let you use it like a monad instead of using explicit pattern matching.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 2 years ago* (1 child)

    Well, in Rust, it’s a sum-type

    The discussion is on to use monads in C++, and not on why is C++ different than Rust.

    I repeat: you do not need sum types to implement a Result monad in C++.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 2 years ago

    The discussion was about sum types. The top-level comment, the one to which you originally responded, says:

    It's a shame that sum type support is still so lacking in C++. Proper Result types (ala Haskell or Rust) are generally much nicer to deal with, especially in embedded contexts.

  • permalink
  • fedilink
  • source
  • parent
    • [–] 7 points 2 years ago* (1 child)

    Don't use exceptions in C++ anymore

    /s

  • permalink
  • fedilink
  • source
  • hideshow 2 child comments
    •
    • [–] 5 points 2 years ago

    Another alternative to C++ exceptions (instead of return code) is to use global (or thread local) variable. This is exactly what errno that C and POSIX are using or GetLastError what Windows is using. Of course, this has its own pros and cons.

  • permalink
  • fedilink
  • source
    •