Back to Basics: Exceptions - Klaus Iglberger - CppCon 2020
Vložit
- čas přidán 4. 10. 2020
- cppcon.org/
github.com/CppCon/CppCon2020/...
---
Exceptions are the native error propagation mechanism in C++. If used properly, exceptions enable us to write simpler, more readable and more robust code. However, the path there can be tricky and unfortunately the exception mechanism isn't without flaws. This talk sheds somelight on the current issues with exceptions and why a large part of the C++ community isn't using them. It also gives guidelines and best practices on how to deal with exceptions and how touse them properly. It will go into detail about the exception safety guarantees, explains the tradeoffs between them, and demonstrates by example the individual steps necessary to reach them.
---
Klaus Iglberger is a freelancing C++ trainer and consultant. He has finished his PhD in computer science in 2010 and since then is focused on large-scale C++ software design. He shares his experience in popular advanced C++ courses around the world (mainly in Germany, but also the EU and US). Additionally, he is the initiator and lead designer of the Blaze C++ math library (bitbucket.org/blaze-lib/blaze...) and one of the organizers of the Munich C++ user group (www.meetup.com/MUCplusplus/).
---
Streamed & Edited by Digital Medium Ltd - events.digital-medium.co.uk
events@digital-medium.co.uk
*-----*
Register Now For CppCon 2022: cppcon.org/registration/
*-----* - Věda a technologie
The top C++ experts tend to be trainers than actual programmers. It says a lot about a language when understanding its details is a field in itself.
As I see it, it is a language where practical research is done. Other languages makes then the best practises, which has been found out by experimenting in cpp, mandatory.
@@tilmanrotationalinvariant2257 if you're talking about actual research, C++ isn't it. It's a very practical tool, but cutting edge isn't it.
C++ is unfortunately a language where academics settle their tenure at the expense of engineers.
@bobweiram6321 and thank God for that, I highly prefer to have C++ experts to be teachers, by sharing their knowledge we can build upon it, and make ourselves become experts to pass on the knowledge and hopefully make things better for the next generation of C++ devs
You didn't need 1 hour to tell me not to use exceptions. Just the first 5 minutes convinced me.
Nice presentation, good to go over the fundamentals.
The slide said "How to deal with failing cleanup functions" in RAII but the discussion was more around which API to use to be notified of a failed attempt to close a file. I guess the message here could be "if you can't cleanup in the destructor - you're out of luck and have either leak the resource (for example, leave the mutex locked if that could fail) or terminate()"
Great talk, thank you!
Oh man.. is there a part of this video that recommends exception over features that exists in Modern C++? Did I miss something?
Btw, you know that presentation is really good when you thought the video ended in 30 minutes but actually has 1 hour runtime. Excellent video!
great talk on exception
For slide 78, shouldn't this->pr be reset if w.pr is nullptr? Otherwise it'll have the old Resource.
Great talk, Klaus!
Excellent presentation skills and very helpful contents!
Glad it was helpful!
4:09 I still not use these Exception,
The remarks around not throwing exceptions in case of bugs, and that asserts should be preferred, are odd to me. As far as I can tell, the only acceptable production-viable implementation of asserts is in terms of exceptions. A bug happening somewhere doesn't mean that your entire process needs to be unceremoniously brought down; you can at the very least still log what happened. In many cases, you should even be able to continue work on subsequent work units, canceling only the one that caused the problem. This is a perfect fit for exceptions.
Slide 78. Don't we end up with multiple unique_ptr pointing to the same object? Shouldn't such a class be movable only ?
No. The old unique pointer's destructor is called before the new object is assigned
It's not copying the pointer. It's making a new Resource using the Resource's copy constructor to initialize the new heap-allocated Resource.
try {
auto i = try to_int("12");
auto d = try divide(42, i);
}
Who rated this "9" for noise? Were they thinking that higher number = more noise or something? It's terrible, hope it never becomes standard.
TL;DR: Exceptions in C++ still suck and are not worth the effort. Maybe someday. Representative quote: "Exceptions are great because that's the only way to report errors from constructors! Oh, by the way, you cannot throw exceptions from destructors. Because ... it's complicated. So, yeah, just, well, write exception-safe code, man." I'm sticking to error-codes. Or, rather, absl::Status and absl:StatusOr. Let me know when exceptions no longer suck.
100% agree. Don't want to fall off the cliff? Stay away from the rim.
Nope, exceptions are still great. Not having to write a bunch of boilerplate just to ferry error information up and down is brilliant. In practice, you don't want to throw from destructors anyway so it's not a serious limitation. Sounds like you need more experience with them.
At 11:11 there is a small misprint - The main function should have " return 0;" in another case this program have formally undefined behaviour. Super cool talk!