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

101–110 of 115 posts

Re: C++ Core Guidelines

#101

Post by m_mueller »

laneb wrote: post #70
m_mueller wrote: post #53

Earlier quoted context omitted.

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

My point is, that part of python is IMO a bit ugly. Not due to naming, but because these are exceptions. A type system with good use of optionals across the standard lib is certainly more elegant than ValueError.

Re: C++ Core Guidelines

#102

Post by rramdin »

jandrewrogers wrote: post #90
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…

A common pattern for dealing with failures on construction, such as the example above, without using exceptions is for the object to be constructed in a null state (often useful in any case) and implementing a 'explicit operator bool()' overload that evaluates to false if construction failed or is intentionally null. Of course, that means you have to actually check that construction was successful, similar to returni…

But how is requiring the programmer to know that he has to check error codes and whatnot any different from requiring the call be place in a try/catch block?

Most cases where exceptions are useful are when the alternative is knowingly causing such a state that will inevitably lead to a seg fault. It's much easier to raise at the point of failure instead of trying to limp until the application eventually crashes or loses you all your money.

Re: C++ Core Guidelines

#103

Post by stonemetal »

krylon wrote: post #98
mehrdadn wrote: post #55

Earlier quoted context omitted.

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

Throwing an exception is explicit as well.

Re: C++ Core Guidelines

#104

Post by frankzinger »

RustGirl wrote: post #86
quotemstr wrote: post #66

Earlier quoted context omitted.

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.

I started out as a rust True Believer and still am active in the Rust community. But I don't use it anymore for new projects because it really doesn't bring anything new to the table. At my current job, I'm knee-deep in C++.

> because it really doesn't bring anything new to the table.

What about the built-in memory and concurrency safety?

Re: C++ Core Guidelines

#105

Post by pjmlp »

krylon wrote: post #97
jcelerier wrote: post #60

Earlier quoted context omitted.

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

> a) you can catch a segfault, too, by installing a signal handler,

My POSIX knowledge is a bit out of date, but if I remember correctly what actually happens is not guaranteed to work across all UNIXes.

Re: C++ Core Guidelines

#106

Post by Too »

snarfy wrote: post #31
_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…

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…

What's the reasonable alternative to exceptions? Checking return status or errno after every single function call and then manually propagating it upwards? (optional is a bit better but also falls into this category) Programmers are way too lazy for this and it usually ends up as either a redundant assert() crashing the whole application or just logging a error and continue with broken state.

Exceptions is following the "let it crash" philosophy from erlang, instead of broken recovery code scattered all over your code. (Crash doesn't necessarily mean a linux process in this context, more of a high level) This is a very powerful concept that allows you to think about the bigger picture such as if _anything_ unexpected happens inside this transaction, return a error to the user and continue processing the next request from the next user. Error handling should be done by layers, not by grunt work.

There are situations where I agree you might want to know how a certain function can fail, here I think javas checked exceptions strike a good balance between control vs verbosity as you just have to add a throws-clause if you don't want to handle a specific error at that point in the code.

Re: C++ Core Guidelines

#107

Post by Ace17 »

snarfy wrote: post #31
_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…

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…

> No matter how you slice it, exceptions are still a goto under the covers.

This is a poor argument; the same could be said for almost all control flow statements: if/else, while, for, break, continue, (early)return ... they're all implemented using "goto under the covers". Moreover, lots of C programs use goto to do their error handling!

Seeing "throw" statements as gotos misses the point: you can't really create spaghetti control flow using "throw" statements. Instead, you can see them as "return on steroids".

It's true that "try-catch" makes it hard to know where your code is gonna "jump" ; but that's the point : as the "thrower", you don't have to know, and you don't /want/ to know. Think about the standard libraries for Java, C#, Python, D ... they don't have this luxury. If when using "throw", you're wondering "where's the catch", then you /probably/ have a design issue.

Re: C++ Core Guidelines

#108

Post by erik_seaberg »

jandrewrogers wrote: post #90
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…

A common pattern for dealing with failures on construction, such as the example above, without using exceptions is for the object to be constructed in a null state (often useful in any case) and implementing a 'explicit operator bool()' overload that evaluates to false if construction failed or is intentionally null. Of course, that means you have to actually check that construction was successful, similar to returni…

Your code isn't really statically typed if every object might support its declared methods, or might instead be an unusable time-bomb. Much better that an invalid object never exists and code that needs that object isn't reachable.

Re: C++ Core Guidelines

#109

Post by jhasse »

pjmlp wrote: post #105
krylon wrote: post #97

Earlier quoted context omitted.

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

> a) you can catch a segfault, too, by installing a signal handler, My POSIX knowledge is a bit out of date, but if I remember correctly what actually happens is not guaranteed to work across all UNIXes.

Good luck getting a fully C++14 compatible compiler with exceptions working on all UNIXes.

Re: C++ Core Guidelines

#110

Post by jhasse »

lasagnaphil wrote: post #47
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…

About the dependency between constructors and inheritance, I like how rust handled the situation. In rust you do not have any constructors, but instead you can make a factory method that returns an Option or Result , so no need for any exceptions while construction. You can also do this in C++, but you still have to declare constructors anyway, along it being a bit inconsistent with other idiomatic C++ code...

You can make the constructor private :)
Post reply on HN