try/catch
-
I was wondering how many people base their error trapping on try and catch? I read in "Game Programming Gems" that exception handling was "expensive" and I wanted to know if anyone has felt this impact? I am writing a multi-client nonblocking telnet server app and speed can turn into an issue. Would I be better off to do a tradition bool or int error returns? Any input would rock! ---- Xian
-
I was wondering how many people base their error trapping on try and catch? I read in "Game Programming Gems" that exception handling was "expensive" and I wanted to know if anyone has felt this impact? I am writing a multi-client nonblocking telnet server app and speed can turn into an issue. Would I be better off to do a tradition bool or int error returns? Any input would rock! ---- Xian
Game programming and "normal app" programming are entirely different animals. Games are all about speed, speed, and more speed. When you write something like a Telnet app, most of your cycles will be spent waiting for the user to do something, or waiting for data to arrive via the connection. I personally use return values for errors. It's what I'm used to and I would gain nothing by using exceptions. MHO of course. --Mike-- http://home.inreach.com/mdunn/ #include "witty_sig.h" :love: your :bob: with :vegemite: and :beer:
-
I was wondering how many people base their error trapping on try and catch? I read in "Game Programming Gems" that exception handling was "expensive" and I wanted to know if anyone has felt this impact? I am writing a multi-client nonblocking telnet server app and speed can turn into an issue. Would I be better off to do a tradition bool or int error returns? Any input would rock! ---- Xian
try/catch is not expensive if it's used for unrecoverable errors. At that point you're exiting from the game anyhow. Unreal used exception handling and it's a high performance FPS. try/catch is only expensive if it's used to catch normally occuring errors.
Todd Smith
-
I was wondering how many people base their error trapping on try and catch? I read in "Game Programming Gems" that exception handling was "expensive" and I wanted to know if anyone has felt this impact? I am writing a multi-client nonblocking telnet server app and speed can turn into an issue. Would I be better off to do a tradition bool or int error returns? Any input would rock! ---- Xian
-
I was wondering how many people base their error trapping on try and catch? I read in "Game Programming Gems" that exception handling was "expensive" and I wanted to know if anyone has felt this impact? I am writing a multi-client nonblocking telnet server app and speed can turn into an issue. Would I be better off to do a tradition bool or int error returns? Any input would rock! ---- Xian
In addition to the other replies, the "expense" of exception handling greatly depends on how it is (mis)used. For example, wrapping your entire application's code with a single try/catch is not too expensive. But wrapping every single call to "recv(...)" or "send(...)" or every time you process a window messages (if you have a message pump) might be. Peace! -=- James.
-
In addition to the other replies, the "expense" of exception handling greatly depends on how it is (mis)used. For example, wrapping your entire application's code with a single try/catch is not too expensive. But wrapping every single call to "recv(...)" or "send(...)" or every time you process a window messages (if you have a message pump) might be. Peace! -=- James.
Yeah, my main function looks kinda like this :
XGameObj * pGameObj = new XGameObj();
try
{
pGameObj->initGame();
pGameObj->startListener();
pGameObj->gameLoop();
}
catch( const char * pszError )
{
// stuff
}My support functions in my Socket handler throw back errors and if they are bad then I throw them back to the main loop. Other than that I am not doing much with it. I only throw back to the beginning for irrecoverable errors. I hope this is the "proper" way of doing it. I pretty much just figured it out on my own. I dont try/catch every send and receive, plus this is a console app, so no windows pumps! Every heartbeat the events are fired based on time. Like connections are checked and messages are checked every beat, while updates to the queues may occur every 1 real second, etc. I am pretty much just making it up as I go along :) Peace.
-
Yeah, my main function looks kinda like this :
XGameObj * pGameObj = new XGameObj();
try
{
pGameObj->initGame();
pGameObj->startListener();
pGameObj->gameLoop();
}
catch( const char * pszError )
{
// stuff
}My support functions in my Socket handler throw back errors and if they are bad then I throw them back to the main loop. Other than that I am not doing much with it. I only throw back to the beginning for irrecoverable errors. I hope this is the "proper" way of doing it. I pretty much just figured it out on my own. I dont try/catch every send and receive, plus this is a console app, so no windows pumps! Every heartbeat the events are fired based on time. Like connections are checked and messages are checked every beat, while updates to the queues may occur every 1 real second, etc. I am pretty much just making it up as I go along :) Peace.
> Yeah, my main function looks kinda like this : [...] I assume you know this, but without a "catch all" handler, you will not catch things like dereferencing a NULL pointer, or other exceptions. -=- James.
-
> Yeah, my main function looks kinda like this : [...] I assume you know this, but without a "catch all" handler, you will not catch things like dereferencing a NULL pointer, or other exceptions. -=- James.
I assume you know this, but without a "catch all" handler, you will not catch things like dereferencing a NULL pointer, or other exceptions.
I assume you know this, but SEGV is nothing the C++ exception mechanism would usually handle. It's a Microsoft extension. A C++ exception handler (in the context of the ISO C++ standard) handles C++ exceptions. No more, no less. /Mike -
I assume you know this, but without a "catch all" handler, you will not catch things like dereferencing a NULL pointer, or other exceptions.
I assume you know this, but SEGV is nothing the C++ exception mechanism would usually handle. It's a Microsoft extension. A C++ exception handler (in the context of the ISO C++ standard) handles C++ exceptions. No more, no less. /MikeThe astute reader will notice that I did not (nor did anyone else, for that matter) specifically mention "Segmentation Violation", or anything else even close to Unix. -=- James.