Sign in to follow this  

Better or Best Error Handling via signal()

This topic is 2541 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Just had a quick question/idea for you more experienced programmers...

How do you process your errors? Do you use an error handling routine that transforms the information yo a user readable format? Do you log anything? Do you even use a log? Do you use C++'s throw/catch mechanism? I was wondering because I was inspired by all these and a few more and just wondered if any of you have came across the same idea. Any maybe you did it better or more efficiently then I did. So here is how I did it.

First I catch all the signals. I use old-school signal() for now, but later I'm thinking about using sigaction. I hear signal is deprecated so I better hurry. Any ways. The signal handlers auto shutdown my engine's framework. The only special exceptions I make are SIGUSR1 and SIGUSR2. I use SIGUSR1, but haven't quite found a place yet for number 2. Any ways. I've wrote two special procedure Throw and Catch(inspired by C++) that do the error handling. Throw takes an error identifier and a string describing the error. Throw formats the error using the parameters specified and triggers SIGUSR1 via kill or raise. I use either of those two since raise is more/less a wrapper for kill. The actual signal handler, the one mapped via signal, calls Catch if the signal is SIGUSR1/2 or it just shuts every thing down and calls exit. In Catch, if the error is fatal, in some cases it will be, the error is printed and/or logged then exits the process with exit.

I handle errors this way so I don't have to keep calling and checking error routines. All my functions return void and if any error does happen, they would call Throw needed. Throw will eventually triggers signals only if an error is great enough. This also makes the code cleaner because only the core/system routines need to Throw errors and I don't have a bunch of mess constantly checking for errors and other things. They just run right through. Fast and clean that way I think. What about you?

Share this post


Link to post
Share on other sites
Quote:
Original post by mind_wipe
How do you process your errors?


Depends on the error and the application.

Quote:

Do you use an error handling routine that transforms the information yo a user readable format?


I suppose you could consider error.ToString() similar to that...

Quote:

Do you log anything?


Sometimes. Depends on the error, the application, and the runtime parameters (generally).

Quote:

Do you even use a log?


Usually. Depends on t...

Quote:

Do you use C++'s throw/catch mechanism?


When I use C++, and the scenario warrants it. Generally I prefer designing scenarios where things can't fail (understanding that sane default behavior counts as 'success').

Quote:

First I catch all the signals. snip


...okay. That seems... ghetto for lack of a better term. Reproducing try/catch without the stack unrolling seems... to defeat the purpose.

Share this post


Link to post
Share on other sites
I though it was cool any ways. Hmmm... I was using the signals to trap errors and make sure shutdown procedures were called. I used the C++ throw and catch names because there kinda cool and its what I was doing. Throw and error, then Catch the signal and do error processing. I though it was a bit cleaner. Do you have a better way? For example...


void InitGameStuff()
{
if ( !InitSound())
Throw( ERR_FATAL, "Failed to initialize sound." ) ;

// init other stuff...
}



What I'm trying to do is localize all the error detection in one place. Also, the rest of the modules only have to know about Throw. Then, depending on the error I would shutdown/log the error. So I guess you know all this all ready, but what I was trying to do is make a more efficient and easy to use error/event handling scheme. The program just uses signals to throw errors or notify about special ones.

You have a better approach? I would really like to know if you don't mind.

Share this post


Link to post
Share on other sites
Not knowing anything about what's going on, I'd be inclined towards...


void InitGameStuff(){
InitSound();
// etc.
// let InitSound throw actual exceptions for the really bad stuff
// and let whatever calls this determine what is a fatal error.

// Generally, I'd pass some sort of log instance/interface
// down into the sound module, since it should determine
// what to log, but I (the caller) determines where it goes
}




Nothing fancy. It's error handling. It just needs to work.

Share this post


Link to post
Share on other sites

This topic is 2541 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this