https://bugs.kde.org/show_bug.cgi?id=371933
--- Comment #3 from RJVB <rjvber...@gmail.com> --- Kevin: judging from the report title they certainly appear to be related. DrKonqi didn't serve up any candidate related tickets though, but that's maybe just another feature that didn't survive the BKO upgrade. Sven: I know it's an assert (which is a form of check...), but I'm not convinced it's a required one in the sense that the unexpected situation cannot be handled any other way than by provoking a crash. If that's the case a version should be used that doesn't disappear in release builds. I have the impression that more than a few developers use this as quick and dirty alternatives to a proper check and error handling when a situation isn't supposed to arise. I've worked with and wrote enough of my own complex code to have accepted the practical fact that you cannot always presume that things will be error proof and work as you intended, esp. when you're dealing with asynchronous events and a human-in-the-loop. You're right that one should try to fix the underlying cause, but that may not be feasible, and in any case that is not an excuse for not handling the situation gracefully if at all possible. Imagine a crash like this occurs when you try to do a patch review, forgot to save and you never get to the proposition to save your changes. That said, if the crash really occurs in m_view_to_action.value() it might also occur in m_view_to_action.contains() if `view` is the culprit here (stale pointer?). I'd expect the return value from m_view_to_action.value() to be undefined when the item isn't in the table, and thus a crash in some unpredictable later statement. Is it possible that `view` is something that should be released through deleteLater() rather than delete? -- You are receiving this mail because: You are watching all bug changes.
