|
Guest
|
Some years ago, my team decided that throwing exceptions was to
forbidden in code that will eventually compile into production
releases. At the time, this was also the accepted view for the
majority of games development teams, particularly those working on
consoles, mobiles and handhelds where time and memory resources are
very limited.
As I remember, the reasons were as follows:
(1) Exceptions allocate memory on the heap. Many games have multiple
heaps. Many have no global new and delete.
(2) Throwing and catching exceptions is very slow
(3) High memory cost. If we compile with exception handling turned on
in the compiler's options, the executables turn out much larger than
if turned off, even not a single throw statement was to be seen.
(4) Your production program shouldn't have any errors, so they're
redundant.
So, I'd like to open up the discussion on this topic. Here are my own
thoughts about this:
(1) Can't this be solved by overriding new and delete for the
exception class being thrown?
(2) Is this still true? To be honest, I don't fully buy it (although I
have to no empirical evidence), but suspect that throwing exceptions
may actually be the fastest way method of error handling in some
cases. (For instance, if and error happens deep within a call stack
and you want to back out without, repeatedly checking error status
flags.)
(3) Is this still true? (I suspect so, since the C++ standard mandates
exceptions in many situations, so, even your code doesn't throw any
exceptions, the compiler generated code, and the standard C library
may do.) Is it a big deal on modern consoles?
(4) Well, its true production games shouldn't crash, but the whole
point of exceptions is to allow you to handle an error and not crash.
Also (2), they may be the most efficient way of dealing with some
legitimate cases and so are not redundant. |
|
|
