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

71–80 of 112 posts

Re: Problems with C++ exceptions

#71

Post by 1718627440 »

mgaunard wrote: post #48
themafia wrote: post #20

Earlier quoted context omitted.

You can use goto to jump to one of several exit conditions based on the level of cleanup you need. It also nicely unifies all error exits into one place. The kernel makes heavy use of this style.

sure, but that has limitations as well, since gotos can't cross lexical scopes, so you can't introduce variables later on, and it's easy to mess up. Destructors are a higher-level and safer approach.

> since gotos can't cross lexical scopes, so you can't introduce variables later on

That's a C++ specific limitation, it works just fine in C.

Re: Problems with C++ exceptions

#72

Post by 1718627440 »

gorgolo wrote: post #30

I didn’t really understand the writer’s comments with exceptions and I don’t code in C++. Their main complaint about exceptions seems to be that you can’t handle all of them and that you don’t know which you’ll get? If we compare this to python, what’s the difference here? It looks like it works the same here as in python; you catch and handle some exceptions, and others that you miss will crash your program (unless…

> would the author have similar problems with python?

I would expect yes. It is true, that in a lot of modern languages you need to live with that dynamism. But to people used to C, not knowing that the error handling is exhaustive, feels deeply uncomfortable.

Re: Problems with C++ exceptions

#73

Post by apple1417 »

gorgolo wrote: post #30

I didn’t really understand the writer’s comments with exceptions and I don’t code in C++. Their main complaint about exceptions seems to be that you can’t handle all of them and that you don’t know which you’ll get? If we compare this to python, what’s the difference here? It looks like it works the same here as in python; you catch and handle some exceptions, and others that you miss will crash your program (unless…

In normal use it's essentially the same yes. The one interesting edge case that might catch some people out is there's actually nothing special about std::exception, you can throw anything, "throw 123;" is valid and would skip any std::exception handlers - but you can also just catch anything with a "catch (...)".

Re: Problems with C++ exceptions

#74

Post by 1718627440 »

ranger_danger wrote: post #56
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).

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.

Re: Problems with C++ exceptions

#75

Post by 1718627440 »

mgaunard wrote: post #11
lealanko wrote: post #7

This is a common problem with try-catch syntax. An alternative, and arguably more useful syntax would be try (File_handle fh {s, "r"}) { // use fh } unless (const File_error& e) { // handle error } Where the "use fh" part is not covered by the exception handler. This is covered (in ML context) in https://www.microsoft.com/en-us/research/publication/excepti...

Don't use try/catch in the first place; that's where his error lies.

That's not his own invention, but an idea introduced by the language founder to sell the idea of RAII and exceptions. He did say, that he would prefer the C version, but then why use C++ in the first place.

Re: Problems with C++ exceptions

#76

Post by 1718627440 »

mgaunard wrote: post #50
matu3ba wrote: post #38

Earlier quoted context omitted.

> 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…

Well, he's using try/catch locally. You're not supposed to handle errors locally with exceptions. The whole point is inversion of control, you manage them at the point where you can do meaningful recovery, which then triggers the cleanup of the whole stack of frames once the exception bubbles up, rather than systematically cleaning up on the normal control flow path. Regardless, in his example, he could achieve what…

> Well, he's using try/catch locally. You're not supposed to handle errors locally with exceptions.

Tell that to Bjarne!

Re: Problems with C++ exceptions

#77

Post by Someone »

thomasmg wrote: post #53
Someone wrote: post #27

Earlier quoted context omitted.

> 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…

> And so the caller has to be prepared for everything: a later version of the library might suddenly return a new type of exception.

But you get the same with checked exceptions in Java. Yes, an interface will say foo can only throw FooException, but if you want to do anything when you get a FooException, you have to look inside to figure out what exactly was wrong, and what’s inside that FooException isn’t limited.

A later version of the library may suddenly throw a FooException with a BarException inside it.

Re: Problems with C++ exceptions

#78

Post by marler8997 »

gorgolo wrote: post #30

I didn’t really understand the writer’s comments with exceptions and I don’t code in C++. Their main complaint about exceptions seems to be that you can’t handle all of them and that you don’t know which you’ll get? If we compare this to python, what’s the difference here? It looks like it works the same here as in python; you catch and handle some exceptions, and others that you miss will crash your program (unless…

"You can't handle all of them and you don't know which you'll get" is a great summary of the first two problems, and, this same problem also applies to Python. I'll add that these only start becoming an issue when you start adding more exceptions to your codebase, especially if those exceptions start appearing deep in a callstack and seemingly unrelated code starts needing to be aware of them/handle them.

The third problem (RAISI) is a C++ specific problem that Python doesn't have. Partly because in Python try/catch doesn't introduce a new scope and also partly because Python tends not to need a lot of RAII because of the nature of interpreted languages.

I found this video a fascinating take on comparing C++ to Python if you haven't seen it: https://www.youtube.com/watch?v=9ZxtaccqyWA

Re: Problems with C++ exceptions

#79

Post by marler8997 »

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 talks about possible solutions, all of which aren't great. I think however these problems with exceptions don't manifest into bigger issues because programmers just kinda learn to avoid exceptions. So, the post was trying to go into why we avoid them.

Post reply on HN