3 ms·

Exceptions are a control flow mechanism, not necessarily an error collection mechanism. I also frequently work with languages either without exception handling

Exceptions are a control flow mechanism, not necessarily an error collection mechanism. I also frequently work with languages either without exception handling or with exception handling disabled for certain targets. Even when exception handling is enabled, it's a bit silly and heavyweight if you just need to short circuit a single conditional, loop, or function. Why throw when you can break or return? And when you do use nonfatal-but-logged exceptions, what do you put in the exception handler and what makes it different from assertAndContinue besides minor errata like being specialized for exceptions?

wvenable 8y ago
> I also frequently work with languages either without exception handling or with exception handling disabled for certain targets. In those cases, you definitely cannot use exceptions but I'm still not sure I'd use something like assertAndContinue. If an assertion has failed, something has gone terribly wrong and I can't imagine just continuing. > it's a bit silly and heavyweight if you just need to short circuit a single conditional, loop, or function. Why throw when you can break or return? You throw because it's an error condition, you break or return because that's a potential the normal flow of operation. It's not heavyweight because it's for a state that should potentially never happen. > And when you do use nonfatal-but-logged exceptions, what do you put in the exception handler and what makes it different from assertAndContinue besides minor errata like being specialized for exceptions? All exceptions are "fatal" to the current operation, however you define it. It could be fatal to the entire application, bringing it down completely. Or it could just be fatal to a single function, request, or even UI button click. In comparison, assertAndContinue() would continue the current operation in, by definition, an invalid state.
- MaulingMonkey 8y ago
  > If an assertion has failed, something has gone terribly wrong and I can't imagine just continuing. For most traditional uses of asserts, sure. There's plenty of edge cases you might not want to ship with but aren't fatal if they do ship however. In a game this might be something like missing leaderboard definitions. Sure, losing player scores sucks, but it's not as bad as crashing the game outright and losing their progress. It's worth crashing the game at QA time to force it to get fixed, it's worth silently logging in production to avoid even bigger losses to the player. I consider those checks a variation on assertions, and "assertAndContinue" sounds like exactly the sort of thing you'd use for exactly this kind of check. Maybe you don't call them assertions...? > You throw because it's an error condition, you break or return because that's a potential the normal flow of operation. It's not heavyweight because it's for a state that should potentially never happen. Exceptions take full stack traces in a number of languages. Even in those that don't, compilers usually optimize for the exception-free path and basically ignore the performance of the exception handling path. And just because it "should" never happen doesn't mean it doesn't happen frequently enough to cause perf bugs. One example: A title I worked on had significant framerate problems if you pawed at the screen just right. The cause? Exceptions thrown from system APIs on invalid touch/finger IDs when querying finger positions. Because they invalidated the IDs before finger up events could be processed. It could've returned an invalid state, returned the last known finger position for that ID in release builds, or done any number of faster error handling paths and it wouldn't have even been noticed as a problem. Instead, it threw, I doublechecked there wasn't any way to pre-query the finger IDs or process finger up events faster/in time, added a terrible catch statement, and just ate the performance hit. Exceptions are heavyweight. Sometimes not so terribly so that they're the wrong tool for the job, but sometimes they are. > All exceptions are "fatal" to the current operation, however you define it. It could be fatal to the entire application, bringing it down completely. This is the nonfatal-but-logged case I was specifically referring to. Again: What do you put there? > In comparison, assertAndContinue() would continue the current operation in, by definition, an invalid state. Any code invoking assertAndContinue has presumably taken measures to properly handle the continue path, likely by simply aborting the operation being asked of it. Just like any code that uses a try/catch construct presumably would.

wvenable 8y ago

> I also frequently work with languages either without exception handling or with exception handling disabled for certain targets. In those cases, you definitely cannot use exceptions but I'm still not sure I'd use something like assertAndContinue. If an assertion has failed, something has gone terribly wrong and I can't imagine just continuing. > it's a bit silly and heavyweight if you just need to short circuit a single conditional, loop, or function. Why throw when you can break or return? You throw because it's an error condition, you break or return because that's a potential the normal flow of operation. It's not heavyweight because it's for a state that should potentially never happen. > And when you do use nonfatal-but-logged exceptions, what do you put in the exception handler and what makes it different from assertAndContinue besides minor errata like being specialized for exceptions? All exceptions are "fatal" to the current operation, however you define it. It could be fatal to the entire application, bringing it down completely. Or it could just be fatal to a single function, request, or even UI button click. In comparison, assertAndContinue() would continue the current operation in, by definition, an invalid state.

MaulingMonkey 8y ago
> If an assertion has failed, something has gone terribly wrong and I can't imagine just continuing. For most traditional uses of asserts, sure. There's plenty of edge cases you might not want to ship with but aren't fatal if they do ship however. In a game this might be something like missing leaderboard definitions. Sure, losing player scores sucks, but it's not as bad as crashing the game outright and losing their progress. It's worth crashing the game at QA time to force it to get fixed, it's worth silently logging in production to avoid even bigger losses to the player. I consider those checks a variation on assertions, and "assertAndContinue" sounds like exactly the sort of thing you'd use for exactly this kind of check. Maybe you don't call them assertions...? > You throw because it's an error condition, you break or return because that's a potential the normal flow of operation. It's not heavyweight because it's for a state that should potentially never happen. Exceptions take full stack traces in a number of languages. Even in those that don't, compilers usually optimize for the exception-free path and basically ignore the performance of the exception handling path. And just because it "should" never happen doesn't mean it doesn't happen frequently enough to cause perf bugs. One example: A title I worked on had significant framerate problems if you pawed at the screen just right. The cause? Exceptions thrown from system APIs on invalid touch/finger IDs when querying finger positions. Because they invalidated the IDs before finger up events could be processed. It could've returned an invalid state, returned the last known finger position for that ID in release builds, or done any number of faster error handling paths and it wouldn't have even been noticed as a problem. Instead, it threw, I doublechecked there wasn't any way to pre-query the finger IDs or process finger up events faster/in time, added a terrible catch statement, and just ate the performance hit. Exceptions are heavyweight. Sometimes not so terribly so that they're the wrong tool for the job, but sometimes they are. > All exceptions are "fatal" to the current operation, however you define it. It could be fatal to the entire application, bringing it down completely. This is the nonfatal-but-logged case I was specifically referring to. Again: What do you put there? > In comparison, assertAndContinue() would continue the current operation in, by definition, an invalid state. Any code invoking assertAndContinue has presumably taken measures to properly handle the continue path, likely by simply aborting the operation being asked of it. Just like any code that uses a try/catch construct presumably would.