4 ms·

I'd go one step further - throw your own exceptions whenever you can. Just put assertions in your code. Even verbose assertions. Which error report would you ra

• drdaeman 13y ago
  Please, don't even think about such approach if you handle many long-living tasks (like, say, client connections) in a single OS-level unit of execution (process or thread) and the error/exception happens for a single task but crashes the whole stack.
  • V-2 13y ago
    Just make sure they are caught and handled. Your single task should not allow any exceptions to bubble up all the way to the whole stack. Whether they are your own or not.
• 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 ago
    Of 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