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

Current hardware trends make C++ exceptions harder to justify

open-std.org

Post reply on HN
Print view View original

291–300 of 516 posts

Re: Current hardware trends make C++ exceptions harder to justify

#291

Post by pjmlp »

pyjarrett wrote: post #241
pjmlp wrote: post #109

Earlier quoted context omitted.

C++ is the only language where exceptions are such an ideology war. All the other ones that have born with exceptions don't have this issue, including Ada.

Ada exceptions are fundamentally different from C++ since they only carry type data with a possible message and no other user-defined data. Old school C++ used to have additional try/catch blocks (and performance hit) inserted to ensure that functions match the given exception signature. Also, C++ usually focuses on performance, so all of the bookkeeping required for exceptions could historically be the last 3% or so…

FPS rate should not drive what 99% of other C++ developers are able to use the language for.

Re: Current hardware trends make C++ exceptions harder to justify

#292

Post by jcelerier »

JAlexoid wrote: post #142
jerf wrote: post #113

Earlier quoted context omitted.

I kinda look to when the thing finally stabilizes as a sign as to how bad the problem was. For instance, Javascript front end was a nightmare for a long time, but it seems to have finally stabilized into a reasonable stable configuration with a couple of winners, some minor specialized choices, and the endless churn is now a minor sideshow instead of something that is changing the default choice every six months. The…

One of the reasons why I try to avoid C++ is that it's an unopinionated multi paradigm kitchen sink language. There are great uses and great features, but there are so many of them and everyone has their own opinions.... Even in this thread there's a clear subset of people who "adore" C++ exceptions

So interesting, to me a language being opinionated is the main reason to put it on the do-not-use bin. I strongly believe that the best way to develop is through embedded domain-specific languages adapted to individual problems, and opinionated languages are always way too limiting regarding that.

Re: Current hardware trends make C++ exceptions harder to justify

#293

Post by gumby »

shrimpx wrote: post #255
fivea wrote: post #251

Earlier quoted context omitted.

> If you write a jpeg-processing service, it’s intuitive to raise an exception on a malformed jpeg (..) Not really. Having to parse a malformed doc is not an exceptional situation: it's a basic use case, and one which is very close to the happy path.

Your opinion being that you should not use exceptions in that type of case. In which cases should you use exceptions?

My experience in using exceptions (and restartable conditions) over the last 40 years is that exceptions are for things you don't have the ability or "knowledge" (i.e. state) to handle locally.

So a function that ingests a file and processes it may throw an exception if the file isn't found so that the UI can catch it and ask the user for an alternative filename (or to give up and not open a file at all).

If you're connecting to a remote machine and don't get a response, you might throw an exception because you don't know if the user typed the name wrong.

While if you are already talking to a machine and it stops responding it's reasonable to wait a moment and retry, as if could be a transient network brown-out which is something you can deal with on your own.

Re: Current hardware trends make C++ exceptions harder to justify

#294

Post by LightMachine »

josephg wrote: post #257
JoeAltmaier wrote: post #213

Earlier quoted context omitted.

But there's a design pattern where nearly everything is returned as an exception. It's the normal path in some code. I deplore that - its side-effects writ large. But those that use it, find it reasonable and sensible. It's become hard to distinguish right and wrong when it comes to CPU optimization. Different versions of the 'same' CPU can have wildly different sweet spots.

> But there's a design pattern where nearly everything is returned as an exception. It's the normal path in some code. The problem isn’t that C++ exceptions are slow when used the way the compiler expects. The problem is a mismatch between how C++ expects you to use the feature, and how people are actually using the feature. I can’t find the story now, but I read about this happening with Ruby on Rails. Someone dug i…

> Whenever Ruby throws, it allocates 10k of memory and fills it with all sorts of information for debugging - including a full stack trace. And it was doing this work in the background every time someone iterated through an array.

Jesus

Re: Current hardware trends make C++ exceptions harder to justify

#295

Post by zozbot234 »

Koshkin wrote: post #265
TillE wrote: post #200

Earlier quoted context omitted.

"Modern C++ bad" is such a weird HN meme, fortunately it's not an opinion I see a lot elsewhere. Old C++ was awful, the new stuff makes it actually usable. Personally I like how even in embedded code where you don't want to include the standard library, you can still efficiently use language constructs like constexpr, lambdas, etc.

Careful with lambdas, they are not without an overhead.

Lambda is designed to be a zero-overhead feature. In the worst case, it's the same as passing an additional void* ctx argument to a plain old function, which is the most common pattern in C/pre-lambda C++.

Re: Current hardware trends make C++ exceptions harder to justify

#296

Post by taeric »

nybble41 wrote: post #290
taeric wrote: post #233

Earlier quoted context omitted.

I disagree with this. But, I'm also a fan of the condition system in Common Lisp. That is, if the problem is likely one that needs operator/user intervention, the non local semantics of exceptions makes a ton of sense. Indeed, it is useful to have a central handler of "things went wrong" in ways that is cumbersome if every place is responsible for that.

If you read the article by Anders Hejlsberg, he's not arguing against centralized handling of exceptions—the handling of runtime exceptions is expected to be centralized near the main program loop. That, however, is a general-purpose handler which won't have much logic related to any particular kind of exception; it just reports what happened and moves on. You don't need checked exceptions for that. The condition sys…

Fair. Sounds like you are more claiming that most functions would be better returning a result type, but some will be better with more?

I view this as I want my engine to mostly just work. It may need to indicate "check engine" sometimes, though. And that, by necessity, has to be a side channel?

I think that is my ultimate dream. I want functions to have a side channel to the user/operator that is not necessarily in the main flow path. At large, I lean on metrics for this. But sometimes there are options. How do you put those options in, without being a burden for the main case where they are not relevant?

Re: Current hardware trends make C++ exceptions harder to justify

#297

Post by taeric »

layer8 wrote: post #280
taeric wrote: post #229

Earlier quoted context omitted.

I think the question is more on if the implementation of how the jvm does exceptions somehow less affected by core count? That is, the checked part is just a language implementation, right? The jvm doesn't really make much of a distinction. (This is meant as a check to my assumption.)

Yes, that's right, as static type checks generally are. However, the C++ performance issues are unrelated to whether exceptions are statically and/or runtime checked. Furthermore, Java exceptions are not particularly efficient, in particular because they collect the current stack trace on creation by default, which is a relatively expensive operation.

I thought you could tune away the trace on creation behavior.

Regardless, I'd be interested in seeing if this is a performance bottleneck. I'd guess it is only relevant on dataset processing. Closer you are to a place that legitimately can toss to a user, more likely you are to not care?

That is, if the common case of an exception is to stop and ask for intervention, is this a concern at all?

Re: Current hardware trends make C++ exceptions harder to justify

#298

Post by layer8 »

hashmash wrote: post #212
dtech wrote: post #170

Earlier quoted context omitted.

Java's checked exceptions are generally regarded as a mistake. There's a reason no other languages has them, and newer JVM languages (Groovy, Clojure, Scala, Kotlin) treat all exceptions as runtime. Anders Hejlsberg (creator of Delphi, C# and Typescript) also has an excellent article on their problems [1]. In modern Java I see nearly only runtime exceptions used, especially because that's necessary for most Java 8+ l…

Most of the software I write is designed to be fault-tolerant, and checked exceptions are fantastic way of detecting potential faults. The problem is that checking is baked into the exception definition instead of its usage. If I declare "throws NullPointerException", then this should mean I want it to be a checked exception. This should force the caller to catch the exception, or declare throwing it, or to simply th…

The distinction some Java programmers make (including myself) is to treat RuntimeExceptions as indicating interface contract violations (usually preconditions), or more generally, bugs. That is, whenever a RuntimeException occurs, it means that either the caller or the callee has a bug. When existing APIs use RuntimeExceptions to indicate any other error condition, they are wrapped/converted into a checked exception ASAP.

I understand your point about usage-dependend checking. However, I believe it is mistaken. Consider a call chain A -> B -> C -> D, where D throws a checked exception of type X, which C converts into an unchecked exception (still type X). At the same time, B also calls other methods that happen to throw a checked X, and thus B throws a checked X itself, which now, unbeknownst to B, also includes the X from D. B documents the semantic of its X exception, which may not fit the ones thrown by D. Now A catches X, believing the semantics as documented by B, but actually also catches X from D, which was concealed (made unchecked) by C. This breaks checked exceptions in their role as part of an interface contract.

The fact that unchecked exception may originate from arbitrarily deep in the call chain is also the reason why they are unsuitable for defining interface contracts, A function declaring certain semantics for a particular unchecked exception can't realistically ensure those semantics if any function it calls itself must be assumed to also throw exceptions of that type (because it is unchecked). Effectively, you can't safely document "exception X means condition Y" for your function if any nested calls may also throw X for unknown reasons.

Re: Current hardware trends make C++ exceptions harder to justify

#299

Post by zabzonk »

turminal wrote: post #29
zabzonk wrote: post #26

> As illustrational example consider this small code fragment: Consider this crap small code fragment. Any function that returns void is almost certainly wrong.

Enlighten us, please

Any function that does not return a value must have a side effect, else why call it. Calling functions that have side effects (and particularly don't indicate if the side effect was succesful), is not a great idea.

Re: Current hardware trends make C++ exceptions harder to justify

#300

Post by foldr »

jcelerier wrote: post #286
foldr wrote: post #262

Earlier quoted context omitted.

This would mean that attempting to open a file that doesn't exist shouldn't throw an exception. But that is exactly what it does in the standard libraries of many languages with exceptions.

Not in C++ I believe ?

The C++ standard IO library doesn't enable exceptions by default, but IIRC that's just a relic of the fact that it dates back to when C++ didn't have exceptions.
Post reply on HN