2 ms·
> Unwinding the call stack in a game is a no-no. For the most part, I agree, which is why I said they're probably only appropriate in games when used judicious
by dhess 16y ago
> Unwinding the call stack in a game is a no-no.
For the most part, I agree, which is why I said they're probably only appropriate in games when used judiciously, e.g., for fatal errors.
- palish 16y agoExceptions are actually nice for single methods, even in a game. void Horse::ImOnA() { try { Giddyup(); if (IsDead()) EX_ERROR("Guess I wasn't on it."); if (IsFlippingTheFuckOut()) EX_WARN("Safety hazard! Get the f outta the way!"); Feed(); } catch (CException& ex) { ex.Process("Horse::ImOnA() - ", NO_THROW); } CleanupAfterHorse(); } If the horse is dead, then "Horse::ImOnA() - Guess I wasn't on it." will be printed to the console. If the horse is acting like my mother, then "Horse::ImOnA() - Safety hazard! Get the f outta the way!" will be printed to the console. Etc. So this is a nice way to report errors. It's basically a typed goto. But don't you dare try to use it for flow control! >:( You can report various "levels": EX_DEBUG, EX_WARN, EX_ERROR, EX_FATAL ex.Process() checks what kind of exception it is. And for EX_FATAL, for example, it will terminate the application (after writing the message to a log file). It's quite nice to use exceptions in this way, because you rarely ever need to even think about making your methods "exception safe" at all.