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

81–90 of 112 posts

Re: Problems with C++ exceptions

#81

Post by paulddraper »

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.)

It causes big problems in Java.

For example, it plays poorly with generics. (Especially if you start doing FP, lambdas.)

If Java added union types, it wouldn't be a big deal, but AFAIK this is still a limitation.

Re: Problems with C++ exceptions

#82

Post by paulddraper »

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.

Algebraic types, immutable structures, lambdas, higher-order functions.

I think FP receives a lot of "credit."

Albeit the "pure" FP languages aren't popular, because 99% FP is really hard.

Re: Problems with C++ exceptions

#84

Post by _dky »

If C++ had a contract on what exceptions a function can throw with compile time check to enforce caller catches those exceptions, would it make it better?

Guess Java does that, not much experience in Java here.

Re: Problems with C++ exceptions

#85

Post by ranger_danger »

1718627440 wrote: post #74
ranger_danger wrote: post #56

Earlier quoted context omitted.

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).

A kernel will make use of asm, and can't abstract over the machine, so it will always be unportable and relying on compiler extensions.

The Linux kernel did not always rely on compiler extensions though...

Re: Problems with C++ exceptions

#86

Post by thegrim33 »

marler8997 wrote: post #79
SuperV1234 wrote: post #21

This post completely misunderstands how to use exceptions and provides "solutions" that are error-prone to a problem that doesn't exist. And this is coming from someone that dislikes exceptions.

I avoid using exceptions myself so I wouldn't be surprised if I misunderstand them :) I love to learn and welcome new knowledge and/or correction of misunderstandings if you have them. I'll add that inspiration for the article came about because It was striking to me how Bjarne's example which was suppose to show a better way to manage resources introduced so many issues. The blog post goes over those issues and talk…

No offense, but why did you decide to write an instructional article about a topic that you "wouldn't be surprised that you misunderstand"? Why are you trying to teach to others what you admittedly don't have a very solid handle on?

Re: Problems with C++ exceptions

#87

Post by gpderetta »

smallstepforman wrote: post #37

My biggest beef with exceptions is invisible code flow. Add the attribute throws to function signature (so that its visible) and enforce handling by generating compiler error if ignored. Bubbling up errors is OK. In essence, this is result . Thats OK. Even for constructors. What I dislike is having a mechanism to skip 10 layers of bubbling deep inside call stack by a “mega” throw of type which none of the layers know…

I would also like to have type checked exceptions in c++ (as long as we can also template over exception specifications).

But what I would really want is noexcept regions:

   ...
   noexcept {
       ...
   }
   ...
i.e. a way to mark regions of code that cannot deal with unwind and must only call non-throwing operations.

Re: Problems with C++ exceptions

#88

Post by 1718627440 »

ranger_danger wrote: post #85
1718627440 wrote: post #74

Earlier quoted context omitted.

A kernel will make use of asm, and can't abstract over the machine, so it will always be unportable and relying on compiler extensions.

The Linux kernel did not always rely on compiler extensions though...

The kernel once did not need asm? That's a compiler extension, although a popular one.

Re: Problems with C++ exceptions

#89

Post by marler8997 »

thegrim33 wrote: post #86
marler8997 wrote: post #79

Earlier quoted context omitted.

I avoid using exceptions myself so I wouldn't be surprised if I misunderstand them :) I love to learn and welcome new knowledge and/or correction of misunderstandings if you have them. I'll add that inspiration for the article came about because It was striking to me how Bjarne's example which was suppose to show a better way to manage resources introduced so many issues. The blog post goes over those issues and talk…

No offense, but why did you decide to write an instructional article about a topic that you "wouldn't be surprised that you misunderstand"? Why are you trying to teach to others what you admittedly don't have a very solid handle on?

None taken :) I think sharing our thoughts and discussing them is how we learn and grow. The best people in their craft are those who aren't afraid to put themselves out there, even if they're wrong, how else would you find out?

Re: Problems with C++ exceptions

#90

Post by munchler »

raincole wrote: post #58
munchler wrote: post #13

Earlier quoted context omitted.

`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.

OK, but it wasn't until functional programming came along that tagged unions were recognized as a natural way to implement sum types, which is how they are used in modern programming. The old idea of a "variant" has pretty much faded away.
Post reply on HN