C++ Core Guidelines • Hacker News Board

Re: C++ Core Guidelines

#91

Post by blub » Fri, Mar 09, 2018, 3:56 PM UTC

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…

Sure they are :) I think that, together with std::optional and futurestd::expected could be a very robust error handling strategy for C++.

Re: C++ Core Guidelines

#92

Post by jnordwick » Fri, Mar 09, 2018, 3:57 PM UTC

otabdeveloper2 wrote: post #87

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…

You've obviously never written any C++. The point of templates is precisely the fact that they make debugging easier, by replacing runtime assertions and bugs with cryptic compile-time error messages. Figuring out a compiler error is significantly easier than having to debug a malfunctioning test.

You've obviously never tried to debug template heavy code. They are like ugly black boxes - you get an answer (maybe correct maybe not) or you get pages of incomprehensible often useless error messages.

If c++ wanted a meta language, they really should have created one long ago instead of continuing this template madness.

Re: C++ Core Guidelines

#93

Post by blub » Fri, Mar 09, 2018, 4:15 PM UTC

AstralStorm wrote: post #63

jgh wrote: post #14

Earlier quoted context omitted.

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

Calling get on an empty optional is a programmer error though, not unlike dereferencing an invalid ptr, so throwing would be an improvement. :)

Most code would check or call value_or, buggy code would throw. There's still the complication of the unsafe std::optional interface, which can only be solved by wrapping/rewriting IMO.

Re: C++ Core Guidelines

#94

Post by luk32 » Fri, Mar 09, 2018, 5:47 PM UTC

boltzmannbrain wrote: post #16

I recommend the tl;dr version from Kate Gregory at CppCon 2017, “10 Core Guidelines You Need to Start Using Now”: https://www.youtube.com/watch?v=XkDEzfpdcSg

Haha. I have it opened in my browser waiting for some prolonged work interruption.

I guess I have to dedicate and report 1h for learning and self-improvment during next week.

Re: C++ Core Guidelines

#95

Post by PopsiclePete » Fri, Mar 09, 2018, 5:47 PM UTC

quotemstr wrote: post #45

dullgiulio wrote: post #40

Earlier quoted context omitted.

No, think of panic() as unhandled Segmentation Fault (and other Go specific unrecoverable errors). You can handle Segmentation Fault, but you need to know what you are doing. In Go it's the same.

Panic is _semantically_ the same as throw. That Go culture treats panic like evil voodoo doesn't change how the language construct works.

Nobody in Go culture treats it as "evil voodoo" that I'm aware of. There are clear guide-lines. User passes in a path to a file that doesn't exist and you attempt to open it? Return an error. That's not "exceptional" or "programmer error" - it's just normal "shit happens". You have an array-like structure with 10 elements and your function that modifies it gets passed in index 13? That's probably a bug or programmer error, not "user" error - so panic.

Go documentation is very clear on the difference between the two, actually. I've never been confused.

Re: C++ Core Guidelines

#96

Post by dang » Fri, Mar 09, 2018, 6:16 PM UTC

rootlocus wrote: post #51

dang wrote: post #2

Discussed in 2015: https://news.ycombinator.com/item?id=10239962

Ignored 4 months ago: https://news.ycombinator.com/item?id=15540452

Yup. The convention here is only to link to the posts that received discussion, since users get ornery when they click on a link and nothing's there.

Re: C++ Core Guidelines

#97

Post by krylon » Fri, Mar 09, 2018, 6:51 PM UTC

jcelerier wrote: post #60

dullgiulio wrote: post #40

Earlier quoted context omitted.

No, think of panic() as unhandled Segmentation Fault (and other Go specific unrecoverable errors). You can handle Segmentation Fault, but you need to know what you are doing. In Go it's the same.

But panic is recoverable in go, with "recover()". That's literally the same mechanism than exceptions with a different syntax and keywords.

Strictly speaking, a) you can catch a segfault, too, by installing a signal handler, and b) recover() is not quite the same, because with "real" exceptions, you can state in a catch clause what types of exceptions you handle, and the compiler/runtime will do the right thing, where in Go, you call recover() and look at the return value to see if there is something you can do about it. And if not, I do not think you can even "re-throw" the panic further up the stack.

(I think the panic()/recover() mechanism is intentionally crude in order to discourage people from over- or abusing it.)

Re: C++ Core Guidelines

#98

Post by krylon » Fri, Mar 09, 2018, 6:52 PM UTC

mehrdadn wrote: post #55

snarfy wrote: post #31

Earlier quoted context omitted.

Exceptions are a mistake, plain and simple. They should have never been added to the language. They break the notion of programming as a sequence of events. With exceptions, now you have two sequences, the happy path and the 'wherever the hell the exception is caught' path. No matter how you slice it, exceptions are still a goto under the covers. If they are truly exceptional, you might as well call exit() too. Go go…

> They break the notion of programming as a sequence of events What about coroutines...?

Switching between coroutines is explicit, i.e. it will not catch you by surprise.

Re: C++ Core Guidelines

#99

Post by quotemstr » Fri, Mar 09, 2018, 6:54 PM UTC

to3m wrote: post #83

quotemstr wrote: post #68

Earlier quoted context omitted.

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…

Sure, you can do this, but don't. Approximately the last thing you want is a copy constructor that can fail. If you have to do an OS call to duplicate the underlying resource, assume the class isn't copyable in this way. It's almost certainly possible to make it moveable, and this will get you the bulk of the benefit: you can return it from functions, and you have a std::vector of it. (Also worth noting that close (2…

> Sure, you can do this, but don't.

It was instructive. That said, there's nothing wrong in general with a class that owns a file descriptor, and making this class copy constructible as a legitimate design decision.

> Also worth noting that close (2), which presumably you'd call from the destructor, can fail with EIO or EINTR.

IO errors from close(2) should be ignored. If you care about durability, call fsync before you close. Even if close "fails" with an IO error, the underlying FD is still closed. EINTR does not actually happen.

See extensive discussion http://austingroupbugs.net/view.php?id=529

Re: C++ Core Guidelines

#100

Post by krylon » Fri, Mar 09, 2018, 7:08 PM UTC

pknopf wrote: post #82

_xzxj wrote: post #7

I wish they were more specific about when to use and not use exceptions. Truth be told I really hate exceptions and I strongly feel that they should only be used in the most disastrous situations. I'm messing with the 0MQ C++ wrapper now (which I will probably move off of) and they use exceptions for freaking everything. For example the send(msg) method returns true if the message is sent, false if EWOULDBLOCK is ret…

People gripe at Go's error checking, claiming it's verbose, etc. But, I like it. Fully and clearly expressed intent for the handling of errors.

In a programming language that allows functions with multiple return values, error values of some sort become almost natural. In Lua, the idiom of returning "nil, errormessage" on failure is very common, too.