Try Catch

Started by
17 comments, last by DevLiquidKnight 20 years, 8 months ago
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
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.
yea i just dont know how to use it?
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]
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
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.
Please use a source tag instead of a code tag. Thank you.
Not to be picky, but you should actually catch exceptions by reference. That way, a base catch statement will also catch derived exceptions.

<
[Creating a Scripting System in C++]
[MinGW] [V IDE]
[boost] [STL] [STLport]
[SDL] [OpenGL] [OpenAL] [DevIL]
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.
daerid@gmail.com
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.

This topic is closed to new replies.

Advertisement