Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

DevLiquidKnight

Try Catch

This topic is 5450 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

I have wondered I have never really understood the purpose of implmenting try { } catch() statements into my C++ code I know they suppose to be useful for finding errors or somthing but i just dont understand how they work id like to find a tutorial or somthing or even have someone explain exactly when and why to use them as well as how to use them If that makes any sense but if someone does respond please dont huge a huge vocab I dont know many C++ terms. I know a few but not ALL Of them lol coder requires 0xf00d before continue().
Killer Eagle Software

Share this post


Link to post
Share on other sites
Advertisement
errors, or more specifically, extremely rare events that designing around make your code ugly.

for instance, I''ve got an application with plugins. The application loops over data it recieves and lets the plugin handle it.

Building an interface that passes a ''Done'' flag down a chain of about 20 function calls through different plugins is nasty, and error prone.

Instead, when the plugin is done and doesn''t want to process more data, it throw''s xDone, which unwinds out of all the functions, reaches my main function, is catch''ed (intention misspelling), prints "Done.", and exits.

That''s one situation where it not error handling, but error handling is where something like that situation comes up often.

Share this post


Link to post
Share on other sites
The biggest advantage that of EH that I see is the separation of the user interaction code from the low-level code. If a low-level logic function encounters an error, without EH, you have to call a high-level function (for example, a message box function) to show the error message (or worse; you simulate EH by returning error codes). You're also unsure what to do, since your low-level function isn't aware (or, at least, shouldn't be aware) of the context in which it was called. EH solves that problem nicely.

EH also encourages you to detect errors correctly the first time around. Without EH, my low-level function would have a temporary call to some aborting sequence that displays the error message and kills the process. When I finally get around to treating the error correctly, I would have to modify the low-level function again (and possibly add an extra argument to it, to specify how the error should be handled). That discourages me from going back and try to correct the error, since I might create new ones in the process.

With EH, I would simply throw an appropriate exception, and never touch the low-level function again. If no specific handler catches the exception, my top-level exception handler will catch it, display the generic error message, and quit. If I decide to handle the exception appropriately, I can go straight to whatever abstraction layer should take care of it, and never modify the interface of any function, or modify the low-level function.

Hope this is not too cryptic...

Cédric

[edited by - Cedric on August 12, 2003 12:44:56 AM]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
And note that exceptions are intended to be used for exceptions, ans not program flow control as I''ve seen examples of. If you have code that always gonna end with an exception it''s not really an exception is it?

/__fold

Share this post


Link to post
Share on other sites
Here''s how you do it:


try
{
//program code goes here
}
catch(Exception e)
{
//handles the error. eg: you could display a notification to the user/developer, try some other way of doing something (ie if you''re changing display modes), etc...
//you can use this to find out what the error is:
MessageBox.Show(e.Message);
//this will pop up a message box with the error message (ie null pointer, invalid value, etc, etc, etc).
}


Besides, it''s less annoying than your program unexpectedly pausing and switching to the debugger to tell you that you didn''t do you code right.

Share this post


Link to post
Share on other sites
EH makes my life easier, because I can write code that is expected to succeed, and let exception handle the exceptional conditions in which the code doesn''t.

Makes the logic of the program easier to read and follow.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by Anonymous Poster
And note that exceptions are intended to be used for exceptions, ans not program flow control as I''ve seen examples of. If you have code that always gonna end with an exception it''s not really an exception is it?

/__fold


Except that said program may intend to run for months or even years processing data, and the termination of the program IS an exception.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!