Exception, assertions AND return codes?

[cboard_member]

Should I be using them all? Well, I'm only thinking about using exceptions - right now I'm using assert to test for conditions that must be met and are "never" going to be false, leaving return codes for everything else.

Thoughts? Should I use exceptions? Am I abusing any of this?

[matsp]

It's all depending on what you want to achieve.

Assert is a good debug tool - it is rarely useful for the end user of the finished application to see that "Assertion ptr != NULL failed on line 666 in c:\myapp\src\evilmodule\evil.c", but it's a great help when a junior developer is running some test-code and managed to make it assert here - you will immediately know what went wrong and where [ok, so you still have to reproduce it and figure out why your ptr variable is NULL when it shouldn't be, but it's better than a crash].

Return values as error indicators are not that great. But return values as results from functions are GREAT. Compare:

if (isSomething(x)) ...

with

bool result;
isSomething(x, result);
if (result) ...

But using return values to indicate success or failure of the function itself is not a great plan if you are using exceptions generally.

--
Mats

[cboard_member]

Okies, thankies

[Elysia]

Asserts are good for conditions that typically means you did something wrong in the code instead of some problem that might happen in runtime.
Otherwise asserts can be good if there's something you haven't implemented yet, and so if that condition occurs, you can assert to tell you that you need to fix it.
It's also good at finding invalid program states, such as corrupted data somewhere and such. That's where asserts really shine.

Both returns and exceptions has their advantages/disadvantages as well.

[cpjust]

Use asserts to test things that should always be true in debug mode.
For internal functions use exceptions to report errors.
For external functions (i.e. API module boundary functions) translate exceptions to return codes (See: Don't allow exceptions to propagate across module boundaries).

[pheres]

To be exact the link says:

Don't allow exceptions to propagate between two pieces of code unless you control the compiler and compiler options used to build both sides

And that condition is often met. I would avoid return codes as often as possible because every single code introduces a new execution path together with an own unit test you'll have to design and implement (if you want to avoid introducing even more errors while handling them).

Use assertions for everything what needs to be fixed in the source code. Use exceptions to react to "uncommon behavior" which can't be handled locally.

There is also another common level of error handling for software running already at the costumer: Logging. This should of course only be enabled if errors are occurring which can't be reproduced immediately.

[cpjust]

To be exact the link says:
And that condition is often met. I would avoid return codes as often as possible because every single code introduces a new execution path together with an own unit test you'll have to design and implement (if you want to avoid introducing even more errors while handling them).

Yes, if it's all internal to your application that's fine. But if you provide some API's that 3rd party code can call, you have to translate the exceptions into return codes. Conversely, if you call a lot of 3rd party API's, it might be useful to write some abstractions for those functions that convert the API return codes into exceptions...

[pheres]

Yes that sounds reasonable.

[brewbuck]

To be exact the link says:
And that condition is often met. I would avoid return codes as often as possible because every single code introduces a new execution path together with an own unit test you'll have to design and implement (if you want to avoid introducing even more errors while handling them).

Exception propagation is itself an execution path. Just using exceptions instead of return codes doesn't relieve you of the task of testing the error paths.

Use assertions for everything what needs to be fixed in the source code. Use exceptions to react to "uncommon behavior" which can't be handled locally.

Agreed. Exceptions should be used to report, well, exceptional conditions. Note that this doesn't necessarily mean "error condition." Some error conditions are normal and common. These cases, I think, should be handled by return codes.

Of course, RAII changes things a little bit, since the only way to report an error condition from a constructor is to throw an exception. But that's okay with me.

[matsp]

Agreed. Exceptions should be used to report, well, exceptional conditions. Note that this doesn't necessarily mean "error condition." Some error conditions are normal and common. These cases, I think, should be handled by return codes.

Oh, yes, I agree with that. Take for example reading a file, and getting to the end of it will perhaps only give SOME of the requested data, because we didn't know at compile time how big the file is. This is definitely a case of "return the amount of data to the user" [which may be zero bytes if we attempt to read after having reached the end of file].

On the other hand, if we have a file with fixed size records, and we get "half a record" because the file ends abruptly rather than where having a full record, then that's a broken file, and a suitable thing to make an exception for.

--
Mats

[pheres]

Exception propagation is itself an execution path. Just
using exceptions instead of return codes doesn't relieve you of the task of
testing the error paths.

Lets use an example:

int displayImage()
{
  int err = loadImage(...);
  if(-5 == err)// not enough memory. can't be handled here
  {

     return ...;
  }
  err = blitImage(...);
  if(-28 == err)// init display system failed. cant be handled here
  {

      return ...;
  }
  [...]
}

int main()
{
  int err = displayImage(...);
  if()// out of mem
  if()//display subsystem failed
}

and using execptions

void displayImage()
{
  loadImage(...); // may throw out of mem

  blitImage(...); // may throw init failure
  [...]
}

int main()
{
  try
  {
    displayImage(...);
  }
  catch(const out_of_mem&)
  {
     //free some and retry
  }
  catch(const init_failure&)
  {
    // reset something and retry
  }

}

Ok, the number of execution paths seems to be the same for both variants so my statement about it was wrong. But the first one needs a lot of conditions which are error prone to write. This could be a point for exception handling

[anon]

Ok, the number of execution paths seems to be the same for both variants so my statement about it was wrong. But the first one needs a lot of conditions which are error prone to write. This could be a point for exception handling

There seems to be another execution path with exceptions: uncaught exception. And that is one advantage of exceptions: you might forget to handle some possible error codes from a function and the program won't tell you. (Of course, you might handle error codes in a switch, add a case for no error and a default case.)

And another case for exceptions: what if displayImage want's to report true or false if it finished successfully (the return value would mean something different than whether we got to the end of the function)? It would be awkward to return both the boolean and an error code.