One trick is to use macros for the try... catch blocks. The Unreal engine does this nicely. They have 2 try macros - guard and guardslow, and the correspsonding catch macros unguard and unguard slow. guard/unguard are always defined, but the guardslow/unguardslow are only defined if a special define (something like USEGUARDSLOW) is defined. If you implement a similar mechanism, you can use testing and profiling to determine where exception handling slows you down, and change your giards to the slow version in those cases. Then you can turn them off if you need to.
The Unreal macros also implement a stacktrace mechanism which is quite useful.
Exceptions or return values?
quote:Original post by Arild Fines
To say that exceptions should only be used for fatal errors is dogmatic and silly. If they were, we wouldn''t have a catch statement.
Well, last time I checked, we still had a goto statement in C++... And your point is?
We also have the [] operator for indexing into arrays. Does that means it''s dogmatic and silly to use pointer arithmetics instead?
I agree, the important thing is that they''re called "exceptions". They''re for when something exceptional happens, something that normally shouldn''t happen.
Using Arild Fines'' kind of logic, if they were for use with all and any errors, they''d be called something like "error handlers", and not "exceptions".
Some errors aren''t really surprising. Sometimes the player will attempt to do something silly, like trying to walk through a wall, attempt to pick up ammunition he can''t carry, or jump out of an airplane in mid-air. If these are errors from the game''s point of view, return values sounds good to me
Or you might find, when trying to save a screenshot, that the file already exists. So return some kind of error code, and try a new file name. Relatively harmless errors, that 1) can''t be avoided, and 2) should be expected. from time to time.
And "fatal" can easily be defined by the programmer. Or at least predicted. If a harddisk fails, you know in advance that it counts as a fatal error, and can try to handle it as such. If I try to do some invalid action in a game, it isn''t fatal, but merely informs the player that his action couldn''t be executed (maybe by simply not moving the players character, or maybe by sending some kind of actual feedback to the player).
When you implement some kind of error handling, whether it''s through exceptions or return values, you already know whether the error is severe enough to cripple/crash the program.
---------
Life is like a grapefruit. It''s sort of orangy-yellow and dimpled on the outside, wet and squidgy in the middle. It''s got pips inside, too. Oh, and some people have half a one for breakfast
quote:Original post by Invader XI see. I think I just misunderstood the meaning of the word "fatal."
Fatal error means that the program cannot return to normal operation. The catch statement is used to help return the program to normal operation or to close gracefully therefore exceptions are not to be used in only for fatal errors.
quote:Original post by Spoonster
Well, last time I checked, we still had a goto statement in C++... And your point is?
goto is useful. Misuse of goto is not useful.
quote:Original post by Spoonster
Using Arild Fines' kind of logic, if they were for use with all and any errors, they'd be called something like "error handlers", and not "exceptions".
Arild said nothing about using exceptions for all cases. He simply said they are not meant solely for fatal errors.
Colin Jeanne | Invader's Realm"I forgot I had the Scroll Lock key until a few weeks ago when some asshole program used it. It even used it right" - Conner McCloud
[edited by - Invader X on March 1, 2004 1:51:48 AM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
