Exceptions and IF

[kibestar]

Well, I can't see why(or when) should we use exceptions instead of the if statement. Other than catching dynamic memory error, such as bad_alloc(which is standard), I can't see when should we use exceptions rather than if statements.
Or is that the only use of exceptions?

[Bazzy]

if and exceptions are completely different things.
You should use try whenever an exception may be thrown, if when you want to perform something based on certain conditions

[kbw]

Exceptions can relay a lot of context information about an error, whereas a single error code can only return the kind of error.

[Disch]

Exceptions are handy for complex operations where you need to do a bunch of stuff (any one of which might fail) in order for something to be set up. Rather than slipping in a bunch of if statements after every little thing you do, you can just throw an exception. It makes it so that you can write code and just assume that everything has worked, which makes the code much less cluttered.

Plus, since you can catch multiple different exception types, you can clean up partial initialization and do other corrective measures all in the same block of code.

That on top of kbw's point about you being able to give information about the error in the exception.

[jsmith]

Exceptions are also the only way to report errors to the caller from constructors and operators.

[kibestar]

Can anyone give me an example of something I ONLY can do with exceptions? (Without using the standard exceptions). (please!)

[Zhuge]

MyClass::MyClass() { // constructor of my class
    // do constructor stuff
    if(fatal_error) throw some_exception;
}

The constructor can't return a value and you possibly don't want to return an incomplete object. Solution: throw an exception in the constructor.

[Disch]

It's not that you can ONLY do something with exceptions (although Zhuge gave a good example of that), it's that exceptions shorten the error handling process.

Say, for example, you need to do a task that has several steps, each step of which could potentially fail. If any step fails, the whole operation fails.

Without exceptions, to do this you have to check for an error after every step (or sometimes several times in a single step.

Say you want to load an image, modify it, then save it as another file. You could break it into the following steps:
1) Open an image file -- may fail if file doesn't exist
2) Determine its file type (png/gif/jpg/whatever) -- may file is file is not an image, or if it's an unsupported type
3) Load the image -- may fail if file is corrupt or if there's memory errors or whatnot
4) Modify the image
5) Save the image to a new file -- may file if the new file can't be created, run out of space, etc

The error-check method would look something like this:

// if all these functions return error codes:

int errcode = OpenFile( file, path );
if( errcode )  return errcode;

int filetype = DetermineFileType( file );
if(filetype < 0) return filetype;

errcode = LoadImage( file, filetype, image );
if( errcode ) return errcode;

errcode = ModifyImage( image );
if( errcode ) return errcode;

errcode = SaveImage( savepath, image, filetype );
if( errcode ) return errcode;

As you can see, a lot of repetitive code there. It gets even worse if there are things you have to clean up on failure (like closing the file, freeing buffers, etc)

Exceptions get rid of all that by just letting your throw an exception. That way if an exception isn't thrown, you can assume there is no problem, meaning you never have to check for error conditions:

// if all these functions throw exceptions instead of returning error codes:
try
{
  OpenFile( file, path );

  int filetype = DetermineFileType( file );

  LoadImage( file, filetype, image );

  ModifyImage( image );

  SaveImage( savepath, image, filetype );

  return SUCCESS;
}
catch(int errcode)
{
   return errcode;
}

This code is much simpler, cleaner, and easier to follow. Also note that all of the errors go to the same block of code, so if there's any cleanup that needs to be done when it fails, it can all be done in the same area of code.

Of course using a standard exception is better, because you can give more detailed information about the error. You can include a human readable text string and stuff.

[kibestar]

So actually I have to use IF's in the try block? Because in the example listed above you don't throw any exception although there is one being caught (int errcode). Now I'm confused. :P

[Zhuge]

He is assuming that OpenFile() etc functions are now throwing an exception instead of returning an error code in the second example.

[kibestar]

Do you mean:

1- the function itself is throwing an exception? e.g:

void OpenFile(file,path) {
//code...
//code...
//code....
if (error_occures)
throw errcode;
}

or...

2- the try block throws an exception? e.g:

try
{
  OpenFile( file, path ); throw  errcode;

or even....

3- the try block throws an exception depending on something? e.g:

try
{
  OpenFile( file, path );
if (error_occures)
throw errcode;

Do you mean one of these things or something different? (I know I must be really annoying so sorry =/)

Thanks in advance.

[Disch]

1 - The function itself.