Try Catch

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]

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.

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;
}

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.

quote:

---

Original post by Beer Hunter
In C++, yes, but I think langguy''s code was Java.

---

I would say C#

Or maybe Managed C++... I''m not sure how they treat references to __gc classes.

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){....;}
 

Ok the thread has gotten pedantic.

That is definitely C#.

Does Java have a MessageBox class with a static Show function like that? Of course not, in Java it''d be MessageBox.show()!

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]

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;
}

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]

quote:

---

Original post by DevLiquidKnight
try...catch(int expection)

---

Expection handling? Hmmm... could be fun for a joke language.