About Exception in VC++

[wabc]

why we rarely can find using exception in VC++? why we rarely can find the "try{ throw }catch()" sentence in VC++

[Christian Graus]

Because people do not use it ? I only use it if I am doing something where I cannot vouch for my codes ability to run properly, for example, if I am about to try and read a file off the hard drive ( the presence and/or quality of the file are outside my control ). IMO, using try/catch all the time is a sign you don't think you've written the code properly, and is ugly. It also incurs a performance cost. Christian I have come to clean zee pooollll. - Michael Martin Dec 30, 2001 Picture the daffodil. And while you do that, I'll be over here going through your stuff.

[John Clump]

Not sure what you mean. My VC++ code contains many try/throw/catch statements. I often use then in file handling and DAO database I/O.

[Joaquin M Lopez Munoz]

IMO, using try/catch all the time is a sign you don't think you've written the code properly, and is ugly. It also incurs a performance cost. I don't agree with you here. It may look ugly (on aestethics I won't discuss), and certainly it can incur a performance penalty, but you get the following advantages by using exceptions instead of traditional error codes à la Win32 API:

1. The performance penalty is usually only incurred when an exception actually is thrown (which is assumed to be rare). The overhead of having a try/catch block is usually negligible (between 3 and less than 10 asm instructions).

2. Exceptions can improve performance and code size in cases where a lot of error codes have to be checked:

   // without exceptions
   if(foo1(...)!=OK){
   ...
   }
   if(foo2(...)!=OK){
   ...
   }
   ...
   if(foon(...)!=OK){
   ...
   }
   // with exceptions
   try{
   foo1(...);
   foo2(...);
   ...
   foon(...);
   }
   catch(...){
   ...
   }

3. Exceptions are sometimes the only reasonable way to go (eg. when a ctor fails).

4. Exceptions integrate seamlessly with the RAII (Resource Acquisition Is Initialization) idiom. They help support invariants in your classes.

5. They can help you simplify the signatures of your functions: instead of

   BOOL getWhatever(int &whatever);

   or

   int getWhatever(); // -1 if it fails

   you can write

   int getWhatever(); // throws couldnt_do_it if it fails

I think the main problem with exceptions is that they came too late to the standard, so a huge set of code is already out there that does not use them. Also, the throw specification in function declarations is basically broken due to backwards compatibility issues. In these respects, newer exception-oriented languages like Java are in a far better position. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

[alex barylski]

I think what he means is (incase you were asking) Exception handling was included in C++ because C style error checking is almost tedious and would cause confusion to the reader. If you checked the ret value on each function call that would compile into bulky slower code.

if(printf("hey") < NULL)
AfxMessageBox("Error");

Exception handling requires extra type info, which I think is where the slower execution stuff comes in, the crapola is figured out at run time instead of at compile. So I agree with him there, yes it's slower, but I also thought it was the prefered method of error checking. It's the new way. Besides if you can avoid testing the return on each function certainly this would out-weigh exception handling? Have a day!! :) "An expert is someone who has made all the mistakes in his or her field" - Niels Bohr

[Christian Graus]

Joaquín M López Muñoz wrote: don't agree with you here. It may look ugly (on aestethics I won't discuss), and certainly it can incur a performance penalty, but you get the following advantages by using exceptions instead of traditional error codes à la Win32 API: I don't think you understood me - I said ALL THE TIME, in other words, I would absolutely use exceptions to detect and respond to errors, but I took the original poster to mean 'why don't more functions get writing using try/catch', and the answer is that quite often there are not a lot of potential errors to catch (sometimes none ) and it just isn't a reasonable thing to do. In that context, I contend that try/catch is very useful, but only in situations where you recognise the possibility of an error. Not every function needs to operate in the context of try/ctach. I am a vocal advocate of try/catch as an alternative to goto, your example number two is very similar to stuff I have posted many times. By the way, a BOOL is an int, bool should be used instead. Christian I have come to clean zee pooollll. - Michael Martin Dec 30, 2001 Picture the daffodil. And while you do that, I'll be over here going through your stuff.

[Joaquin M Lopez Munoz]

I think the guy was asking about using exceptions in general, not wrapping all up in try/catch blocks. Please note that he refers to (quote) "the "try{ throw }catch()" sentence". If he's reading this maybe he can make it clear what was his original intent. I am a vocal advocate of try/catch as an alternative to goto, your example number two is very similar to stuff I have posted many times. Good to know we're on the same side. By the way, a BOOL is an int, bool should be used instead. Got me (ouch!) :) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo