Archived

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

Try Catch

This topic is 5234 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
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
Implementing a normal, user-initiated quit in terms of exceptions is laziness and shoddy program design. Quitting isn''t exceptional when the user requested it - exceptions should be exceptional (rare) in nature.

An abnormal event generating an exception that leads to a quit I can understand.

But don''t abuse exceptions as flow control, they aren''t used enough as is and they don''t need a bad reputation:

int main()
{
try
{
myHopelesslyInfiniteLoopICantStop();
}
catch(const QuitException&)
{
}

return 0;
}

Share this post


Link to post
Share on other sites
quote:
Original post by Redleaf
Not to be picky, but you should actually catch exceptions by reference. That way, a base catch statement will also catch derived exceptions.
In C++, yes, but I think langguy''s code was Java.

Share this post


Link to post
Share on other sites
It''s java, because in the Java API, there is an Exception class, and if you want to create any custom exception types, you should inherit from Exception.where it is the generic catch. There is an exception class in but it isn''t as used as Java''s Exception. And if I remember correctly, you should have for C++

catch(const exception& e){....;}

Share this post


Link to post
Share on other sites
catch(expection) more info on what exactly the exepction part can be? i dont get it how do i iknow what i can and cannot put there? Where is it passed in? how does that work? What exactly does the catch part do like what is it catching... What will it be when its caught ect?

coder requires 0xf00d before continue().

Killer Eagle Software


[edited by - DevLiquidKnight on August 13, 2003 12:00:37 AM]

Share this post


Link to post
Share on other sites
quote:
Original post by DevLiquidKnight
whats this do? it does nothing lol its an infinit type of thingy?

#include <iostream.h>
#include <stdlib.h>
#include <stdio.h>


int main()
{
try
{
for(int i=0; ; i++)
{
}
}
catch(int expection)
{
cout << expection << endl;
}
return 0;
}


It goes into an infinite loop.

Please take a look at chapter 1 in this book



Qui fut tout, et qui ne fut rien
Invader's Realm

[edited by - Invader X on August 14, 2003 1:58:50 AM]

Share this post


Link to post
Share on other sites