> If you're wrapping lots of things in try/catch, you're doing something very wrong in the first place. People who think you need to do that are using exception

> If you're wrapping lots of things in try/catch, you're doing something very wrong in the first place. People who think you need to do that are using exceptions wrong. It's no wonder that they come to dislike them. I agree something has gone terribly wrong. But in this case, it's the initial API design. Not my fault! > Your example sounds like a badly structured piece of code. If your finger-query code is racing against your event processing code, that's a bug. You violated the function's contract. The exception was telling you about the bug. Don't shoot the messenger. That's what it sounds like, and if the original API was sane you'd be correct. The original API was not sane. As I recall, this might've been when handling finger moved events, that the position query threw, because a not-yet-recieved finger up event had already invalidated the finger. One could say that I violated the contract by checking the position of released fingers. But that contract was designed in such a way as to be impossible to consistently fulfill. It's terrible API design, and arguably a bug, but not my bug - I just wrote the workarounds. One can share blame with the API authors, but this is a reoccuring pattern with APIs that use exceptions, so I'm willing to share the blame with exceptions too - they seem prone to misuse. > Maybe you wanted to write the moral equivalent of optional<Coordinate> getFingerPosition(FingerID finger). Nothing stops your using the optional value pattern in exceptional code. The API I exposed (wrapping the underlying system API) was similar. Well, I didn't use optional, because my API wasn't prone to race conditions despite the underlying system API being prone to race conditions. (Returning a position that's been stale for a few milliseconds seemed acceptable in that case.) Of course, this had the performance problems I mentioned earlier, but those were fundamentally unfixable. > I'm sympathetic. Should contracts be more explicit in code? Sure. In C++, the default should be noexcept, and it should be a compiler error to call a non-noexcept function from a noexcept one. But that's an argument for doing exceptions better, not an argument for abolishing them. Except I've yet to see exceptions done well. Java tried to go a step further with checked exceptions, but that turned out pretty poorly too. I have yet to see exceptions done well, which is an argument for abolishing them until such a time as someone does do them better. EDIT: Particularly topical in this thread - almost every single exception system I've ever used has caused me grief trying to translate errors across C ABI boundaries at some point or another. Per https://doc.rust-lang.org/nomicon/unwinding.html https://doc.rust-lang.org/nomicon/unwinding.html, unwinding across FFI boundaries is undefined behavior - and I've seen some really nasty bugs from C++ exceptions, C longjmps, C# exceptions, Ruby exceptions, etc. all trying to unwind over ABI boundaries too. And then I get to try and sanitize a whole slew of call sites to not invoke undefined behavior. Yuck. > If a pointer is null where it's not supposed to be null, you crash. That's a contract violation, and failing fast in the face of contract violation is the right thing to do. Are you one of those people who writes out null checks at the start of every function? I dislike code like that very much. There are plenty of cases where optional-and-missing values are represented with null in most null supporting programming languages. I'll typically lean towards the null object pattern to get rid of the null checks where sane and possible, but sometimes null checks are the sane and simple solution. This is the case I was asking about. But sure, let's cover cases where it's not supposed to be null too. I won't just check/bail/ignore, that's terrible for the debugging and bug finding experience. But I probably don't want megs of minidump and a confused end user's error report, just because they installed a mod pack that was missing a sound asset resulting in a null pointer somewhere, either. Just crashing is also unacceptable - I want the error report, which I might not get, and the gamer is probably happier with a missing sound effect instead of a crash. Instead, I'd rather insert a null check. For the dev side, you can have your check macros insert an automatic breakpoint, log (for the mod makers), report the error via sentry.io (for catching released bugs in your unmodded game), or even explicitly crash for your internal builds (so you and QA can find bugs). Just as easy to debug as a crash (if not easier thanks to smart error messages), much less end user angst.