Exceptions the Other Way Round - Sean Parent - CppNow 2022
Вставка
- Опубліковано 7 жов 2024
- Slides: github.com/boo...
CppNow Website: www.cppnow.org
CppNow Twitter: @CppNow
---
Exceptions the Other Way Round - Sean Parent - CppNow 2022
When discussing exceptions, there is a focus on when to throw an exception and how to propagate it. But little attention is given to how to recover from an exception. By looking at error handling from what it means to recover from a mistake, we can understand the requirements to handle exceptions correctly. We'll see the technique of shifting perspectives is more broadly helpful in developing usable operations and types.
---
Sean Parent
Sean Parent is a senior principal scientist and software architect managing Adobe's Software Technology Lab. Sean first joined Adobe in 1993 working on Photoshop and is one of the creators of Photoshop Mobile, Lightroom Mobile, and Lightroom Web. In 2009 Sean spent a year at Google working on Chrome OS before returning to Adobe. From 1988 through 1993 Sean worked at Apple, where he was part of the system software team that developed the technologies allowing Apple’s successful transition to PowerPC.
---
Videos Filmed & Edited By Bash Films bashfilms.com/
UA-cam Channel Managed By Digital Medium Ltd: events.digital...
#Boost #Cpp #CppNow
A UA-cam feature to skip interruptions in a conference talk would be good
You actually can add chapters in UA-cam, but this has to be done by the content creator.
Another 'smart-arse interruption special'. Its a one-hour talk, with 45 minutes of constant interruptions. Well done, guys, you smashed up another talk!
This is a great and very interesting talk and Sean Parent really did a good job getting his point across. However, people interrupting the talk and even talking over him makes it difficult to watch. With a little bit of hindsight, what it tells is that the talks severely lacks relevant examples close to the statements being made. Indeed, there are a lot of vocabulary, lot of definitions and people kept on arguing about the real meaning of them to finally come up with satisfactory example to illustrate the statement so that Sean could finally resume. I think having relevant example close to the statements would have helped eluding/shortening the questions a lot. I hope this experience did not deter Sean from giving this talk again in the future and I'm looking forward to it.
I think the talk could have been better with examples as you suggest, but I understood what he was saying before a few in the audience started asking him to clarify. And some of those people asking were being quite annoying asking him pedantic questions, when they should have accepted his definitions and let him get on with the talk, even if they thought the definitions could have been tightened. At least some of the questions were people trying to show off how smart they are, not trying to help the presenter give a clear talk.
More strongly, the interruptions destroyed the pedagogic value of this talk and I stopped watching. 😒 Next time, please defer inside-baseball discussions to the ISO subcommittee where they belong.
I think some commenters are overlooking the fact that this talk wasn't given for the benefit of the UA-cam audience. It was given for the benefit of the paying audience in the room, and with that in mind the questions are entirely reasonable.
This is completely impossible to watch. *Way* too many people in the audience who only want to show off how smart they are instead of letting the presenter make his point.
Not all interruptions were required, but good talk.
Beautiful soul wrenching talk... Thank you
Thanks for sharing the SSID and the WiFi password! J
Great talk, thanks for sharing this :^)
1:12:52 Retry is present when asynchronous operations are present. If you have only synchronous operations, the only reason to retry is indeed when you change the state of your system and then retry.
However, simply claiming that we can turn asynchronous operations into synchronous and therefore we don't have to consider this case is, uhm, interesting to say the least.
It'd be nice for this presentation without audiences. I can't follow as people keep arguing.
1:39:25 The overcommit problem with memory allocation makes me furious. If I have two documents open, one with unsaved changes, and I try to open a third very large document without enough memory, that should be able to just throw bad_alloc and undo the attempted memory allocations and give me a cheaper error message popup to say there's not enough memory, allowing me to close and save work. Instead the behavior is that applications have no idea when touching memory will fail and cause them to crash and burn, losing all unsaved work. They have to actively check memory usage, or the user has to disable overcommit for the whole system. How is that acceptable in any context? No matter what programming language you use, you can't even do a basic guard against this? C++ had this problem solved from the beginning with bad_alloc and everyone just ignored it, why?
I 100% agree! The notion of "you can't handle memory exhaustion anyways" is really dumb, yet there are multiple high-profile engineers that keep repeating it... (Same with "well, if a parallel algorithm fails that's gotta be a hard error"...)
There is actually a modern programming language (which competes with C) that cares a lot about allocation failures - Zig.
Search for ”the road to zig 2019” on UA-cam and you will find a great talk by the language creator Andrew Kelly.
This was so helpful!! Thank you
Glad it was helpful!
Thank You So Much Bud
27:20 Saying that if the preconditions are violated the code is wrong therefore we must terminate the program is too harsh and dogmatic. Suppose that the embedded code for a Lunar lander at some point during descent assumes that we are closer to the surface than 200 meters but we can't possibly be farther than 50 meters, and then the radar throws us a 37 meter altitude reading, does that mean that we are morally obliged to crash the program and let the lander crash on the regolith? Indeed, a violation of preconditions means that something is horribly wrong, don't get me wrong; but what if anything we do about it is a matter of policy; it is not written in the sky that the ONLY thing we can do is shut down. In the case of the above example, for sure we have a nasty problem: Either the telemetry glitched on us, and the distance is more like 100 meters, or else a cosmic ray changed the state of a bit in our telemetry tracking variable, and the radar is right. Rather than exit(0), what we should do now is try to determine which theory is correct, and we have several seconds before impact, which should be plenty of time to confirm or deny the one telemetry reading by waiting for subsequent readings. But I love exceptions, don't get me wrong; just that I think we should be using them a lot more wisely. A paint program is not as mission-critical as a lunar lander; but you never know when a crash might lead a user to suicide, or worse, so it's not a bad idea to think about whether it is really necessary to exit a program just because a pixel was supposed to be white but was instead FFFFFE. Maybe emailing the team about the off-white mystery, and then fixing the pixel, is a more useful course to take than terminating the app.
In general it's a valid point that sometimes you want defensive programs that don't just crash but do the nearest best thing if something is wrong.
However, the lunar lander is a bit of a misunderstanding. The accepted range in preconditions is not the same as the expected value range under normal operating conditions.
If you know that your default control system specifies "never call me with more than 50m deviation" in its preconditions, and you call it with 50m+, then this is a bug. The argument is to terminate in (only) that case. All the solutions you mentioned can still be applied though, either widen the preconditions of the control system and handle it there, or dynamically switch to another control method or other sensor input. For most parts of the system, inputs should simply not be disregarded in the "preconditions", but plausibilized/tracked/rejected, and that doesn't clash with the point of view of the talk. ... so that the more narrowly designed system does not get called with out-of-precondition-range values.
No opinion whether the approach presented is right or wrong, but I think this is how to interpret it for that lunar lander case.
Thanks, great talk.
Some questions remain though. In the description of the term "precondition", it is stated that failure to meet an operation's preconditions leads to undefined behaviour. Later on, the definition of the term "safe operation", is guaranteed to be free of undefined behaviour. However, the subclause "even if preconditions are not met" apparently looks to be in contradiction with the definition of "precondition", for which must lead to undefined behaviour if they are not met (unless the set of precondition is vacuously empty).
I've been looking in the standard to make sure I'm not overlooking some details about the precise meaning of "undefined behaviour". I came across 3.65 Note 1:
"... Evaluation of a constant expression (7.7) never exhibits behavior explicitly specified as undefined in Clause 4 through Clause 15. -end note]".
But, clauses 4-15 excludes all the standard library (clauses 16-33). Should this imply that the implementation be required to detect and fail compilation on occurences of those explicitly specified UB from clauses 4-15 (when they occur as evaluation of a constant expression)?
If yes, then it could make sense to categorize UBs into 2 classes: "compile-time detectable UB", and its set complement? (Note: compile time detectable UB need not be detected at runtime).
Can this discrimination of UB, if it is sensible, be of any help in refining the conceptual model of "safety"? Could we say that the original intent behind the term "safe" would be better expressed as "cannot lead to compile-time detectable UB and/or is non deterministic (unspecified) if preconditions are not met"?
As a stupid nitpick, at 38:00 it says on the slide “all other operations […] are implementation-defined and may trap”. I’m quite sure that taking the address of p would be fine; imagine you could do
p = nullptr;
but you could not do
auto pp = &p;
*pp = nullptr;
That would be absurd.
Too bad the questions cannot be heard. On the other hand, this forces the presenter to repeat or summarize them, which is genuinely good.
Sean Parent is great as always, but I can’t fully watch this specific talk. People are keep interrupting and talking all the time, which is not a behaviour you would expect from an adult! Is it hard to write down the question and ask it in the end? Common people, you are in a conference that being recorded, act accordingly!
Gotta agree - it's ok to have a question during the talk (if the speaker allows them instead of deferring question to after the talk), but some of these interruptions really go on way too long...
seriously, they don't let him explain his ideas they just kept wanting to hear themselves make points
I do agree that they went overboard in this particular case but, in general, most presenters prefer an interacting audience (I know I do). Actually, cppnow encourages the audience to make (genuine) questions during the talk.
I think the people that actually went to the conference have the right to carry it out however they please (as long as everyone is ok with it). I didn't pay for this conference and I'm watching this for free in the comfort of my own home, so I'm just thankful for it and I will decide whether to watch it or not, without making demands.
That's what CppNow is for - interaction & discussion. There are relatively few non-presenter people attending.
I disagree. Conferences are held for and payed by the attendees, therefore they get the privilege of interacting with the speaker. I, for one, am grateful for the organisers to publish the recordings online, because I've learnt a great deal from the material presented from this and many other conferences. - Ed.
The statement that errors are about correct code and recoverable situations is interesting. It assumes that the operation has control over what is recoverable situation.
I think this is fundamentally flaved, because this implies a strongly synchronous execution model, where the operation controls the entire state of the machine.
It does not imply a synchronous execution model. The requirements are the same for a concurrent model.
who is not using the trial ()
Thanks so much legend !! Literally the only tutorial that actually WORKED!
TL; DW allowing your objects to be in an invalid state removes all responsibility on you to provide basic exception guarantees, at the cost of your user managing preconditions. For example, the user has to check std::cin.good().