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

71–80 of 115 posts

Re: C++ Core Guidelines

#71

Post by mehrdadn »

AstralStorm wrote: post #64
mehrdadn wrote: post #61

Earlier quoted context omitted.

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

> That is not a programmer error, this is a domain error mostly for math functions or string parsing.

....what in the world? no... for domain errors there's, erm, std::domain_error. C++ Reference/StackOverflow/MSDN/etc. already explain all these. But it seems I have to copy-paste them here?

"Domain and range errors are both used when dealing with mathematical functions." [1]

"std::logic_error reports errors that are a consequence of faulty logic within the program such as violating logical preconditions or class invariants and may be preventable." [2]

"std::domain_error may be used by the implementation to report domain errors, that is, situations where the inputs are outside of the domain on which an operation is defined." [3]

[1] https://stackoverflow.com/a/641972

[2] http://en.cppreference.com/w/cpp/error/logic_error

[3] http://en.cppreference.com/w/cpp/error/domain_error

Re: C++ Core Guidelines

#72

Post by steveklabnik »

quotemstr wrote: post #66
steveklabnik wrote: post #57

Earlier quoted context omitted.

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

It doesn’t break the feature, that’s how the feature is designed. They’re not for error handling. It’s only broken if you try to treat them as something other than what they’re designed for.

Re: C++ Core Guidelines

#73

Post by AstralStorm »

jgh wrote: post #15
ovao wrote: post #12

Earlier quoted context omitted.

Bjarne's guidance has always been to use exceptions only in truly exceptional circumstances. A function that might occasionally fail on bad user input could instead return a std::optional and be marked noexcept (assuming it really doesn't throw). A function that fails to allocate memory, on the other hand, is truly exceptional, so throw std::bad_alloc. The STL unfortunately doesn't always follow this approach, and te…

since optional is a thing now and the standards committee isn't afraid of verbosity maybe we can get std::value_or_error ;)

Like std::future right? You can use that one today.

Re: C++ Core Guidelines

#74

Post by steveklabnik »

AstralStorm wrote: post #67
blub wrote: post #56

Earlier quoted context omitted.

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

This is true of some languages with these constructs (C++, Scala, AFAIK) but not all (Rust, Haskell).

Given that this is a C++ thread, you’re right, but that’s an issue of the particular language, not the idea generally.

Re: C++ Core Guidelines

#75

Post by [deleted] »

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.

[deleted]

Re: C++ Core Guidelines

#76

Post by chi3 »

quotemstr wrote: post #66
steveklabnik wrote: post #57

Earlier quoted context omitted.

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

That's because a panic should never happen in Rust. If it happens, there's by definition a bug which will make the thread crash.

Re: C++ Core Guidelines

#77

Post by blub »

AstralStorm wrote: post #67
blub wrote: post #56

Earlier quoted context omitted.

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

Actually it's UB by default, so first of all, one should either always use optional::value() or wrap the class.

Secondly... yes, that's why exceptions also need good logging/tracing for best results.

Re: C++ Core Guidelines

#78

Post by oblio »

elbows wrote: post #50
oblio wrote: post #41

Earlier quoted context omitted.

You disappoint me pjmlp, you're not a true graybeard unless you use Vim or Emacs :o) The slightly more serious question: is there anything like this in Vim or Emacs-land? I somehow doubt it... I, for one, have never seen something like it outside of the big IDEs (Visual Studio, IntelliJ, etc.)

rtags for Emacs does this, as well as completion, highlighting syntax errors, and various other IDE-like features.

Got any demo for that? I couldn't find the "highlight unused code" thing...

Re: C++ Core Guidelines

#79

Post by usefulcat »

Anyone know what these guidelines are talking about when they refer to a 'final_action' object, or the function/keyword 'finally'? I'm referring to E.19. I could not get the example below to compile even using the newest gcc with -std=c++1y at godbolt.org. It seems potentially useful, if it actually exists.

https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...

Re: C++ Core Guidelines

#80

Post by nuxi »

usefulcat wrote: post #79

Anyone know what these guidelines are talking about when they refer to a 'final_action' object, or the function/keyword 'finally'? I'm referring to E.19. I could not get the example below to compile even using the newest gcc with -std=c++1y at godbolt.org. It seems potentially useful, if it actually exists. https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...

It's supposed to be part of "Guideline support library", see this section: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...

The only implementation so far seems to be from Microsoft: https://github.com/Microsoft/GSL/blob/master/include/gsl/gsl...

Post reply on HN