How to ensure a statement be excuted in C++?

[souldog]

If you are not going to do anything to the
exception that requires a none constant function call
then catching with const
1. Lets the compiler enforce this.
2. Allows for compiler optimizations.


It is entirely unneccessary.

[darwen]

Thanks SoulDog.

Darwen.

[Marco F]

Isn't this a good example for the frequent call to "RTFM" ? From MSDN ("try"):


====

// Example of the try and catch statements
try
{
// Write the file header
file.Write((LPSTR)&bmfHdr, sizeof(BITMAPFILEHEADER));
//
// Write the DIB header and the bits
file.WriteHuge(lpBI, dwDIBSize);
}
catch (CFileException* e)
{
::GlobalUnlock((HGLOBAL) hDib);
throw;
}

::GlobalUnlock((HGLOBAL) hDib);
return TRUE;

====

.. where the ::GlobalUnlock is only needed in the catch block because "throw" is called.

[darwen]

I agree with try..catch blocks you'll never know in a multi-line entry what went wrong unless you do :

try
{
    // line 1
}
catch (whatever)
{
}

try
{
    // line 2
}
catch (whatver)
{
}

try
{
    // line 3
}
catch (whatever)
{
}

See what I mean ? Same as had been said.

I far prefer functions with boolean values to show success or failure.

Darwen.

[darwen]

Never mind the fact that if we're using MFC compilers we should be using

TRY
{
     // code
}
CATCH (CFileException, pFileException) // example
{
}
END_CATCH

Darwen.

[Andreas Masur]

Originally posted by darwen
why should the exceptions be const ?

Why there is rarely a reason to modify the exception itself...

[Andreas Masur]

Originally posted by darwen
The problem with catch (...) means that when a failure in your program occurs then you won't know why it happened.

A GPF might have occurred (not a file error) and catch (...) will trap this and not pass it on.

I always try to catch only the exceptions which I would normally expect from an operation. If something else happens, then I want to know about it.

Only then can I fix a bug which would normally be hidden by catch(...).

I may be wrong of course....

Yes...I simply used it for demonstration purposes and since it was in the original code. The usage of 'catch(...)' should be of course limited (if not avoided).

Nevertheless, eventhough the 'catch(...)' is in there, it does not necessarely protect your application from crashing. Access-violations etc. cannot be caught with that...at least not reliable. I know that some people say, it is working, however, I made the experience that it is not working. In this case, you would rather need to use structured exception handling.

[Andreas Masur]

Originally posted by Marco F
// Example of the try and catch statements
try
{
// Write the file header
file.Write((LPSTR)&bmfHdr, sizeof(BITMAPFILEHEADER));
//
// Write the DIB header and the bits
file.WriteHuge(lpBI, dwDIBSize);
}
catch (CFileException* e)
{
::GlobalUnlock((HGLOBAL) hDib);
throw;
}

::GlobalUnlock((HGLOBAL) hDib);
return TRUE;

====

.. where the ::GlobalUnlock is only needed in the catch block because "throw" is called.

Which actually is a bad example in my eyes since it also creates code redundancy as mentioned earlier...

[Andreas Masur]

Originally posted by darwen
I agree with try..catch blocks you'll never know in a multi-line entry what went wrong unless you do :

try
{
    // line 1
}
catch (whatever)
{
}

try
{
    // line 2
}
catch (whatver)
{
}

try
{
    // line 3
}
catch (whatever)
{
}

See what I mean ? Same as had been said.

I far prefer functions with boolean values to show success or failure.

Well...sorry but I cannot agree here. Based on the shown way I would agree, however, in my opinion one should not go with such a way if there isn't a real good reason for that. You can reduce the scope of the 'try' block to a certain piece of code. In other words, in the given example, reading from a file. If an exception is thrown, you know that something failed while working with the file. Whether it failed to open it or to read from it, it not important in the first place most of the time. Nevertheless, if specific information is required, either there are different exceptions are being throw or you really need to go with the way shown above.

[Marco F]

Originally posted by darwen
Never mind the fact that if we're using MFC compilers we should be using

What kind of a compiler is a MFC compiler ? Normally I'm only using a C++ compiler ...

[GCDEF]

Originally posted by souldog
try
{
statement s1;
statement s2;
statement s3;
}
catch(const someException& e) // thanks for souldog's comments
{
statement s3;
}

The catch block is only executed if an exception is thrown, so
you need to close the file in both places.

const is not always needed on the exception.

This would be a problem if s3 throws an exception.