Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Problems with C++ exceptions

marler8997.github.io

Post reply on HN
Print view View original

51–60 of 112 posts

Re: Problems with C++ exceptions

#51

Post by tcfhgj »

Someone wrote: post #27
thomasmg wrote: post #9

Earlier quoted context omitted.

I saw that in Swift, a method can declare it throws an exception, but it doesn't (can't) declare the exception _type_. I'm not a regular user of Swift (I usually use Java - I'm not sure what other languages you are familiar with), but just thinking about it: isn't it strange that you don't know the exception type? Isn't this kind of like an untyped language, where you have to read the documentation on what a method c…

> isn't it strange that you don't know the exception type? Java experience taught us that, when writing an interface, it is common not to know the exception type. You often can’t know, for example, whether an implementation can time out (e.g. because it will make network calls) or will access a database (and thus can throw RollbackException). Consequently, when implementing an interface, it is common in Java to wrap…

When using a language forcing checked exceptions, you would know, wouldn't you?

Re: Problems with C++ exceptions

#52

Post by ranger_danger »

lynx97 wrote: post #32
mgaunard wrote: post #6

Author completely misunderstands how to use exceptions and is just bashing them. A lot of what he says is inaccurate if not outwardly incorrect. Also Bjarne's control of C++ is quite limited, and he is semi-retired, so asking him to "fix his language" is fairly misguided. It's designed by a committee of 200+ people. Anyway what you want seems to be to not use exceptions, but monads instead. These are also part of the…

Most criticism of C++ comes from people not really into the language. Sure, learning curve might be an issue. But if you are really into C++, there are a lot of things to like about it. At least I do love it. However, only since C++11. Before that, the language felt very strange to me, possibly due to the same effect, I didn't know enough about it.

I'm the opposite. I like C++ but only until C++11. From that point onward, the rules got WAY more complicated, and there's only so much I can/want to hold in my brain at once, I just prefer simpler rules I guess.

Occasionally I do like to use auto or lambdas from C++11 but even then I have to remember more rules for initialization because braces were introduced.

Re: Problems with C++ exceptions

#53

Post by thomasmg »

Someone wrote: post #27
thomasmg wrote: post #9

Earlier quoted context omitted.

I saw that in Swift, a method can declare it throws an exception, but it doesn't (can't) declare the exception _type_. I'm not a regular user of Swift (I usually use Java - I'm not sure what other languages you are familiar with), but just thinking about it: isn't it strange that you don't know the exception type? Isn't this kind of like an untyped language, where you have to read the documentation on what a method c…

> isn't it strange that you don't know the exception type? Java experience taught us that, when writing an interface, it is common not to know the exception type. You often can’t know, for example, whether an implementation can time out (e.g. because it will make network calls) or will access a database (and thus can throw RollbackException). Consequently, when implementing an interface, it is common in Java to wrap…

Yes I know Java and the challenges with exceptions there (checked vs unchecked exceptions, errors). But at least (arguably) in Java, the methods (for checked exceptions at least) declares what class the exception / exceptions is. I personally do not think wrapping exceptions in other exception types, in Java, is a major problem. In Swift, you just have "throws" without _any_ type. And so the caller has to be prepared for everything: a later version of the library might suddenly return a new type of exception.

One could argue Rust is slightly better than Java, because in Rust there are no unchecked exceptions. However, in Rust there is panic, which is in a way like unchecked exceptions, which you can also catch (with panic unwinding). But at least in Rust, regular exceptions are fast.

Re: Problems with C++ exceptions

#54

Post by actionfromafar »

gblargg wrote: post #10
mgaunard wrote: post #6

Author completely misunderstands how to use exceptions and is just bashing them. A lot of what he says is inaccurate if not outwardly incorrect. Also Bjarne's control of C++ is quite limited, and he is semi-retired, so asking him to "fix his language" is fairly misguided. It's designed by a committee of 200+ people. Anyway what you want seems to be to not use exceptions, but monads instead. These are also part of the…

Agreed. Author is trying to mix paradigms. Simplest approach if they want local handling and non-propagation of errors is to just have the file holder not check for open success, and check that manually after construction. Then you get guaranteed closure of file no matter how the function is exited. class File_handle { FILE *p; public: File_handle(const char *pp, const char *r) { p = fopen(pp, r); } ~File_handle() {…

Goes against "Resource acquisition is initialization" though to have objects which exist but can't be used. (I think that's the relevant pattern?)

However, where the language and it's objects and memory ends and the external world begins, like files and sockets... that's always tricky.

Re: Problems with C++ exceptions

#55

Post by imron »

matu3ba wrote: post #38
mgaunard wrote: post #6

Author completely misunderstands how to use exceptions and is just bashing them. A lot of what he says is inaccurate if not outwardly incorrect. Also Bjarne's control of C++ is quite limited, and he is semi-retired, so asking him to "fix his language" is fairly misguided. It's designed by a committee of 200+ people. Anyway what you want seems to be to not use exceptions, but monads instead. These are also part of the…

> Author completely misunderstands how to use exceptions and is just bashing them. A lot of what he says is inaccurate if not outwardly incorrect. Do you mind to elaborate what you believe are the misunderstandings? Examples of incorrect/inaccurate statements and/or an article with better explanations of mentioned use cases would be helpful. > it's called std::expected How does std::expected play together with all ot…

> Do you mind to elaborate what you believe are the misunderstandings?

Exceptional C++, by Herb Sutter is an excellent resource that explains this. It’s quite outdated these days but the core concepts still hold well.

When done well, most of your code can be happy path programming with errors/invalid state taken care of mostly automatically.

However it’s also very easy not to do this well, and that ends up looking like the suggestions the author of the article makes.

Re: Problems with C++ exceptions

#56

Post by ranger_danger »

howtofly wrote: post #41

All this hassle can be avoided by using `cleanup` compiler attribute. Manage classical C resources by auto-cleanup variables and do error-handling the normal way. If everything is OK, pass the ownership of these resources from auto-cleanup variables to C++ ctor. Note this approach plays nicely with C++ exception, and will enter C standard in the form of `defer`.

Yes, but now your code is no longer C or C++ standards compliant as it relies on compiler-specific attributes, if that matters to the programmer.

Unfortunately, even the Linux kernel is no longer C because they use GCC compiler extensions (and are currently discussing adding MS ones too).

Re: Problems with C++ exceptions

#58

Post by raincole »

munchler wrote: post #13
Flundstrom2 wrote: post #2

Java and Rust are the only language that I know of that has proper handling of exceptions; mandatory declaration as part of method declaration, since exceptions ARE an integral part of the contract. (Yes, I consider the Result being corresponding to exception declaration, since the return value MUST be checked prior to use of T.)

`Result ` comes from Haskell's `Either a b` type. F# also has a `Result ` type. It's funny how often functional programming languages lead the way, but imperative languages end up with the credit.

Actually (insert nerd emoji) this is a direct descendant from tagged union type, which existed in ALGLO 68, an imperative language.

Java's checked exception is just an (very anti-ergonomic) implementation of tagged union type.

Re: Problems with C++ exceptions

#59

Post by ignition »

mgaunard wrote: post #6

Author completely misunderstands how to use exceptions and is just bashing them. A lot of what he says is inaccurate if not outwardly incorrect. Also Bjarne's control of C++ is quite limited, and he is semi-retired, so asking him to "fix his language" is fairly misguided. It's designed by a committee of 200+ people. Anyway what you want seems to be to not use exceptions, but monads instead. These are also part of the…

https://godbolt.org/z/363oqqKfv

  struct File_handle {
      static auto Create(std::string const & pp, const char *r) -> std::expected {
          auto p = fopen(pp.c_str(), r);
          if (!p) return std::unexpected(error_code_from_errno(errno));
          return File_handle{p};
      }
      ~File_handle() { fclose(p); }
  private:
      File_handle(FILE * f) : p{f} {} 
      FILE *p;
  };

Re: Problems with C++ exceptions

#60

Post by CoastalCoder »

ranger_danger wrote: post #52
lynx97 wrote: post #32

Earlier quoted context omitted.

Most criticism of C++ comes from people not really into the language. Sure, learning curve might be an issue. But if you are really into C++, there are a lot of things to like about it. At least I do love it. However, only since C++11. Before that, the language felt very strange to me, possibly due to the same effect, I didn't know enough about it.

I'm the opposite. I like C++ but only until C++11. From that point onward, the rules got WAY more complicated, and there's only so much I can/want to hold in my brain at once, I just prefer simpler rules I guess. Occasionally I do like to use auto or lambdas from C++11 but even then I have to remember more rules for initialization because braces were introduced.

This is true of me as well. I started with C++ in 1991, and I generally knew the language spec quite well (as far as users go) up through C++11.

But now the language packs so much complexity that I can't be sure I understand all of the code I'm looking at.

My usual quality standard for production code is that it doesn't just need to be correct, it needs to be obviously correct. So that's a problem.

Doubly so when the other programmers on the team aren't C++ geeks.

Post reply on HN