Discussed in 2015: https://news.ycombinator.com/item?id=10239962
Ignored 4 months ago: https://news.ycombinator.com/item?id=15540452
C++ Core Guidelines
51–60 of 115 posts
Re: C++ Core Guidelines
#52Earlier 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...
> have to declare constructors anyway
At least these days we have class-level initializers to lessen the pain a bit and reduce the number of situations in which you have to write a constructor.
struct foo {
int bar = 5;
};Re: C++ Core Guidelines
#53Earlier 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…
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).
Re: C++ Core Guidelines
#54I 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…
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 you have no control over, so it's not a programmer error) and from a performance standpoint. Example for the latter: say the user gives you a list of hundreds of thousands of files that are to be copied somewhere "if they exist". Imagine half of them don't exist. Now your program is going to have to run through hundreds of thousands of exceptions to signal this.
Re: C++ Core Guidelines
#55I 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…
> They break the notion of programming as a sequence of events
What about coroutines...?
Re: C++ Core Guidelines
#56I 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…
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).
Re: C++ Core Guidelines
#57Earlier 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. 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 an abort, it's not something you can rely on when writing a library, and so I'm not aware of any significant libraries that do so. You couldn't even catch panics for a long time, and the possibility was mostly added to prevent UB with regards to extern functions.
Re: C++ Core Guidelines
#58Earlier 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…
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 if it is inlining the copy function.
The only issue seems to be that few people are able to install or create a good top level error handler in case there is an actual unhandled failure.
Re: C++ Core Guidelines
#59Earlier quoted context omitted.
> I cannot use STL as it is now, even with custom allocators. if you are ready to take the runtime hit you could use the polymorphic allocator support and pass your allocator object down the chain. See http://en.cppreference.com/w/cpp/memory/polymorphic_allocato... ; http://en.cppreference.com/w/cpp/container/vector ; http://en.cppreference.com/w/cpp/container/map . I don't understand why you are making a distinction…
> I don't understand why you are making a distinction between table-like and non-table-like containers: both can take allocators. Because for map in general I cannot know how much allocations and of what size will it need to store 1000 elements. I might glean it for particular implementation of STL, but not via any api. Doing anything bearssl-like, "No dynamic allocation whatsoever", just does not work with STL. > yo…
You can have an idea for sure, that is what profilers are for.
Have datasets of typical execution runs, profile test executions and gather statistics for ideal average sizes.
Gut feeling for sizes never ends well.
Re: C++ Core Guidelines
#60Earlier quoted context omitted.
Well, strictly speaking, Go has panic() which is very similar to exceptions. But it also has a culture that strongly discourages using it unless things go very wrong.
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.