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

C++ Core Guidelines

github.com

Post reply on HN
Print view View original

61–70 of 115 posts

Re: C++ Core Guidelines

#61

Post by mehrdadn »

AstralStorm wrote: post #58
mehrdadn wrote: post #54

Earlier quoted context omitted.

> It's only through exceptions that you can have meaningful copy-constructable resource-holding value types. Could you give an example of this specifically? Are you thinking of e.g. a File class whose constructor opens the file? Because every such example I can think of is one where it ultimately seems inappropriate to me to use exceptions to signal the error. Both from a conceptual standpoint (it might be something…

Exceptions are not for handling programmer errors. Assertions are. Exceptions are indeed used for handling exceptional situations such as actual errors. If you only want to copy a file it it exists, then check if it exists (race-prone but fast) or create a function that copies a file only if it exists. Or you know, swallow the nonexistence exception. An optimizing compiler might be able to elide the throw statement i…

> Exceptions are not for handling programmer errors. Assertions are.

std::logic_error?

Re: C++ Core Guidelines

#62

Post by DrBazza »

This quote from Kernighan should be at the top of any C++ guideline: "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"

Writing supposedly smart code seems to be a weird culture thing in C++.

I've lost count of the number of C++ devs I've worked with that get the "Mmmm, donuts!" reaction to templates, and leave a stinking pile for everyone else to debug. I'm sure I'm included in that group of programmers, but I hope, not as much.

Re: C++ Core Guidelines

#63

Post by AstralStorm »

jgh wrote: post #14
mehrdadn wrote: post #9

Earlier quoted context omitted.

> I wish they were more specific about when to use and not use exceptions. Do you have any examples in mind where it's unclear to you whether an exception would be appropriate?

No because I almost never use exceptions myself (unless consuming them). The only time I would really use it is if for some reason the constructor could fail, but usually in those cases there are better ways of designing the class. Otherwise it's error codes/reasons. Honestly I'm not sure where to draw the line specifically, but I obviously err more on the side of "don't use them". Exceptions in C++ are costly and im…

Any error handling will make control flow explode into checks. Exceptions at least allow you to put the checks in the right place and not necessarily at the point where function is executed.

In typical C code you get to propagate error check statements all the way everywhere or risk bugs. Or use central mechanism like errno and risk thread safety and overwrite while also not knowing about the source of the statement.

In C++ you might have the same problem. Even std::optional (which defers the exception to actual value get) is not best as it loses the information on who made or set it...

Re: C++ Core Guidelines

#64

Post by AstralStorm »

mehrdadn wrote: post #61
AstralStorm wrote: post #58

Earlier quoted context omitted.

Exceptions are not for handling programmer errors. Assertions are. Exceptions are indeed used for handling exceptional situations such as actual errors. If you only want to copy a file it it exists, then check if it exists (race-prone but fast) or create a function that copies a file only if it exists. Or you know, swallow the nonexistence exception. An optimizing compiler might be able to elide the throw statement i…

> Exceptions are not for handling programmer errors. Assertions are. std::logic_error?

That is not a programmer error, this is a domain error mostly for math functions or string parsing. (Other than relatively evil std::length_error/out_of_range which might go either way.)

In most cases where it is a bit gratuitously thrown it can be avoided.

You might want as well to redefine any error as a programmer error.

Re: C++ Core Guidelines

#65

Post by lucozade »

DrBazza wrote: post #62

This quote from Kernighan should be at the top of any C++ guideline: "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" Writing supposedly smart code seems to be a weird culture thing in C++. I've lost count of the number of C++ devs I've worked with that get the "Mmmm, donuts!" reaction to templ…

> how will you ever debug it?

> leave a stinking pile for everyone else to debug

I think you answered your own question. The trick is to leave the debugging to someone twice as clever as you. Job done.

Re: C++ Core Guidelines

#66

Post by quotemstr »

steveklabnik wrote: post #57
quotemstr wrote: post #46

Earlier quoted context omitted.

> They break the notion of programming as a sequence of events. It's never been that way. What's a page fault? > No matter how you slice it, exceptions are still a goto under the covers. "break" is also a goto. What's your point? > If they are truly exceptional, you might as well call exit() too. That's completely unacceptable for robust software. Programs can recover from almost all errors and make forward progress,…

> Even languages that start out vehemently anti-exception, like Go and Rust, end up with the full try-and-catch exception toolkit. Rust (and as far as I know, Go) have pretty much remained the exact same with regards to their implementations here. Go uses panic/recover a bit more liberally than Rust uses panic/catch_panic; using panic for control flow is not idiomatic, and so is not done. Since you can turn them into…

I find it amusing and sad that the Rust ecosystem, via this "panics as abort" feature, replicated one of the worst parts of the C++ ecosystem: -fno-exceptions, which, in C++, turns throws into aborts.

In both language environments, the availability of a compiler option that breaks a language feature doesn't erase the existence of that language feature.

Re: C++ Core Guidelines

#67

Post by AstralStorm »

blub wrote: post #56
quotemstr wrote: post #44

Earlier quoted context omitted.

I strongly disagree with you. I think too few people use exceptions. They're great for making code more expressive, and it's only through exceptions that you can avoid two-phase initialization of classes and make constructors actually useful. It's only through exceptions that you can have meaningful copy-constructable resource-holding value types. Avoiding these constructs severely restricts the language. And for wha…

As lasagnaphil said, with optional and result types exceptions can be restricted to signaling coding errors instead of any errors. Think vector::at (good) versus std::stoi (bad).

What will you do if you do not check if the optional actually has a value?

(What happens: you get an exception at the moment of dereference and potentially lose the information about the cause.)

Re: C++ Core Guidelines

#68

Post by quotemstr »

mehrdadn wrote: post #54
quotemstr wrote: post #44

Earlier quoted context omitted.

I strongly disagree with you. I think too few people use exceptions. They're great for making code more expressive, and it's only through exceptions that you can avoid two-phase initialization of classes and make constructors actually useful. It's only through exceptions that you can have meaningful copy-constructable resource-holding value types. Avoiding these constructs severely restricts the language. And for wha…

> It's only through exceptions that you can have meaningful copy-constructable resource-holding value types. Could you give an example of this specifically? Are you thinking of e.g. a File class whose constructor opens the file? Because every such example I can think of is one where it ultimately seems inappropriate to me to use exceptions to signal the error. Both from a conceptual standpoint (it might be something…

That file class might hold a file descriptor and dup the file descriptor in the copy constructor. If that dup operation fails because you've hit the FD descriptor limit and that copy constructor has no way of indicating that it failed to do its job, you're screwed.

Sure, you can give up on copy constructors altogether and manually manage resource copies, but doing so impoverishes the language, wrecks one of its best features, and makes programs both more verbose and probably a bit slower.

Re: C++ Core Guidelines

#69

Post by AstralStorm »

Leszek wrote: post #23
Matheus28 wrote: post #6

Small annoyance (I haven't read the entire thing, but I have strong feelings about this): gsl::index is disgustingly verbose. If you use stl, just use size_t. If you're using something else, follow the conventions they use (be it size_t, int, or whatever). Their examples [1] conveniently omit size_t to push their alternative. [1] https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...

I think you're missing the point that gsl::index, unlike size_t, is signed.

Ssize_t then. Or ptrdiff_t.

Re: C++ Core Guidelines

#70

Post by laneb »

m_mueller wrote: post #53
XorNot wrote: post #39

Earlier quoted context omitted.

Except Go has panics and they turn up quite a lot looking exception-like. Go with panics moved to regular error returns doesn't seem like it would lose anything.

Maybe panic is just a better name so people don‘t get the idea to use it for control flow in slightly less than normal situations? (i.e. ValueError, StopIteration in python).

Nothing about names like StopIteration and AttributeError indicate to me that I should use them for control flow. Python just instructs me to use them that way...
Post reply on HN