3 ms·
Please use some restraint! Sometimes an exception is not the answer! I've had... I think it was Windows::UI::Input::PointerPoint::GetCurrentPoint throw except
by MaulingMonkey 13y ago
Please use some restraint! Sometimes an exception is not the answer!
I've had... I think it was Windows::UI::Input::PointerPoint::GetCurrentPoint throw exceptions if the finger passed in was no longer touching the screen. Sounds fine at first, right? Except...
1) This occurred before "finger released" events, so you'd run into a crash because they thought throwing an exception was better than returning the last known finger position, which would've rightly left me with no error report.
2) This occurred in a nasty rare corner case, making figuring out the reproduction a PITA. I don't think I'm alone in not expecting such a simple function to throw when given a known-to-me-valid fingerId. Worse, the exception was completely undocumented on MSDN -- either explicitly or as a hint from function signature (at least Win32 had the common decency to return BOOL or HRESULT.)
3) I found no method for validating a finger ID, so one had to simply catch the exception and accept the massive framerate dip of exception handling overhead if the user pawed at the screen. Before you mistake that for hyperbolic performance concerns: I could make a smooth 30fps tank to bellow 10fps consistently. I measured!
Touch input isn't the only unexpected thing throwing exceptions for WinRT. The end result of this "throw exceptions whenever you can" mentality is I've been forced to build a habit of wrapping every WinRT API call in extremely wide try/catch blocks to log whatever random undocumented exceptions come crawling out of it. By becoming the rule, it took the "exception" out of "exceptions". I'm sure you'll agree: This is horrifically ugly, slow, and in generally poor taste.
But it's necessary. The other alternative is you hopefully find as many as 90% of the weird junk that crashes your program with exceptions, most of which you don't actually care about in the slightest -- and the other 10% avoid discovery and instead explode your stuff in production, most of which will be for no good reason.
- V-2 13y agoOf course sometimes exceptions are not the answer... I don't mean one should "throw them whenever they can" in literal sense, like the more the merrier :) Exceptions, as the name itself indicates, should only be reactions to EXCEPTIONAL situations. Showstoppers. The adage is: don't use exceptions for flow control. In the case you described, it seems to me that they did just that, and I don't condone that. It's clearly a case of bad, or at least unfortunate API design... By "whenever you can" I meant "whenever you can once the ground criteria are met", I kind of thought it goes without saying but I should've been more precise