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

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.

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?

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.

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.

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]

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.

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

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