Jump to content
  • Advertisement
Sign in to follow this  
dave

Exception Handling

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

Hi, Ok so i've decided that i should really move on to exception handling. I'd like to ask a few questions: 1. Can you point me to any good resources on this? 2. As a first impression i don't think the idea of having lots of trys and catches all over the code is nice. Is there a way u can reduce this? 3. Should Try-Catch's be used nearly everywhere ANYTHING can go wrong? How far should u go with this? 4. I was playing with them for five minutes and decided i'd try to separate the catch block from the try block by implementing it in a class member function. The idea was that i could then just call this function and handle all exceptions in one place. Is this actually possible since VS6 says i cant have one without the other adjacent? Thanks ace

Share this post


Link to post
Share on other sites
Advertisement
1. *shrugs* a good C++ book I'd guess
2. only put them where logical
3. dont use exceptions all over the place, only where an exceptional event could accure and you need to signal as much, breaking out of the normal program flow (example a critial model file is missing). They are NOT a replacement for error codes and return values.
4. I've no idea what you are on about, but if you are doing what I think you are doing it wont work. Post code.

Share this post


Link to post
Share on other sites
Quote:
Original post by ace_lovegrove
4. I was playing with them for five minutes and decided i'd try to separate the catch block from the try block by implementing it in a class member function. The idea was that i could then just call this function and handle all exceptions in one place. Is this actually possible since VS6 says i cant have one without the other adjacent?
No you can't just like you can't break up an if-else statement like that. I presume you mean the try block in one method and the catch block in one method?

Share this post


Link to post
Share on other sites
2+3) No, you shouldn't have lots of try/catch blocks.
Throw exceptions only in exceptional cases. For instance, if you are trying to open a file that you *need* to open, throw an exception when it doesn't exist. Otherwise, if there's a function that has a good chance of failing, use return codes instead.
Exceptions should only be caught when you know how to handle them. If your file opening utility throws an exception, don't have the function that looks up the filename catch the exception, have the function that actually needs the file handle the exception. The overhead for exception handling really comes into play when an exception is actually being dealt with.

4) No, there's no way to separate the catch block from the try block in a separate function, short of putting both the try and catch blocks outside the function.
If you think about it, it's actually a bad idea, since the function would need some way to know the context of the exception, otherwise it would have to do worst-case handling. I've seen this done by including everything in your program inside a giant try{}/catch(...){} block in your main() function.

Share this post


Link to post
Share on other sites
Quote:
Original post by ace_lovegrove
Hi,

Ok so i've decided that i should really move on to exception handling.

I'd like to ask a few questions:

1. Can you point me to any good resources on this?

A good C++ book
Quote:

2. As a first impression i don't think the idea of having lots of trys and catches all over the code is nice. Is there a way u can reduce this?

You don't need try/catch blocks everywhere, just in those area's where you wish to catch the exceptions.
Quote:

3. Should Try-Catch's be used nearly everywhere ANYTHING can go wrong? How far should u go with this?

Again, use it where it makes the most sense. You should use a catch to catch exceptions at the most logical level possible. In otherwords: no. You shouldn't have try/catch blocks everywhere, just where you need to know about the error.
Quote:

4. I was playing with them for five minutes and decided i'd try to separate the catch block from the try block by implementing it in a class member function. The idea was that i could then just call this function and handle all exceptions in one place. Is this actually possible since VS6 says i cant have one without the other adjacent?

no.

Share this post


Link to post
Share on other sites
Keep in mind that if you use objects that properly clean up after them selves upon destruction like std::auto_ptr or std::vector, the need to use explicit try/catch blocks goes down. RAII is a happy thing.

Share this post


Link to post
Share on other sites
Quote:
Original post by SiCrane
RAII is a happy thing.


Indeed, my life has been much nicer apon useage of this and auto-destructing containers, I cant remember the last time I new/deleted something and not a memory leak in sight, such joy from C++, who'd have thought it [grin]

Share this post


Link to post
Share on other sites
SiCrane has a good point. Exception handling is not about having try/catch littered everywhere (in fact, you should aim for having very little of those), but about having automatic objects that adhere to RAII.

Share this post


Link to post
Share on other sites
You should have very few try / catch blocks.

If an exception occurs way down in the middle of some deeply nested logic, the idea of exceptions is that it automatically unwinds the stack (calling destructors as necessary), to get to your single top-level try/catch block.

Mark

Share this post


Link to post
Share on other sites
So i should use it in most cases where i 'new' an essentialobject or whatever. so like in directxwould it be a good idea to new the creation of the device object?

ace

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

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

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!