views:

101

answers:

6
   int somefunction(bool a)
    {
      try
      {
        if(a)
        throw Error("msg");
        return 2;
      }
     catch (Error const & error)
     {
       //do i need to return anything here??
       //return -1;
     }
    }
+1  A: 

If you won't return anything there, the callee will perhaps do the wrong thing afterwards because the return value will be undefined and perhaps gets one of the valid return codes! Try this:

printf("%i\n", somefunction(false));
printf("%i\n", somefunction(true));

Output:

2
2293512

The compiler also gives a warning for this (f.e. "control reaches end of non-void function").

schnaader
+6  A: 

You need to either return something or re-throw the exception (or throw a new one). You can rethrow the same exception by just using the keyword

throw

in the catch block with no exception or arguments afterwards.

workmad3
A: 

Unless you rethrow the exception you'll need to return an int (presumably an error sentinel value).

marklam
A: 

Depending on your compiler / compiler settings, you will not be able to compile a function returning int that can be left without a return value, i.e. "execution reaches end of non-void function". So yes, you must return a value, unless you want to rethrow the exception.

OregonGhost
+1  A: 

The function returns an int, so you need to return an int. The alternative is not to catch the exception in the function and let it propagate.

anon
+1  A: 

First, by catching in line 9 the exception that you throw in line 6, you are misusing exceptions. You're basically doing what you can do with normal program flow, with an "if" statement. By adding exceptions thrown in this way to your code base, it will be no longer true that exceptions are used for truly exceptional situations. When there is a simple alternative, prefer not to throw exceptions from your functions.

That said, you can exit an int function in two ways:

  • returning an int
  • throwing an exception
Daniel Daranas
If you think it is a misuse, please explain why.
anon
@Neil you're right. I explained it now.
Daniel Daranas
Suppose the if(a) operation can also throw an exception? Then his code makes sense. But I thnk he is just posting a simple example to support his question, rather than real code.
anon
Even then, it's best to leave the catch only for exceptions thrown from below, and treat the more controllable situation with just an "if".
Daniel Daranas
Not if you have a common code. For example, he could want to test "if the evaluation of (a) throws an exception or returns true, do something", in which case what he has seems a reasonable way of doing the "something".
anon
I understand what you're saying, but even in that case it would be better to just call "DoSomething();", or "return DoSomething();", or "DoSomething(); return -1;", twice.
Daniel Daranas
We will have to agree to disagree, I'm afraid.
anon
No problem :) My main point is that a very small duplication (a duplication of invocations) is better than throwing exceptions. I try not to throw exceptions around. Think debugging, think maintenance, think spaghetti code.
Daniel Daranas
I think I understand exceptions, thanks. And I disagree with all your reasons for not using them.
anon
The code may use exceptions unnecessarily, but it's also a concise example that clearly illustrates the question. Replacing the body of the try block with "return someFunctionThatMightThrow(a)" would alleviate your complaint but it would probably also generate some "please post the rest of the code" replies. :)
bk1e
@bk1e, I wasn't objecting to the example code. I was saying that, either in the simplified example or in a fully-fledged one, I'd reserve exception handling code only for catching exceptions thrown from below; and I wouldn't throw an exception from a function and catch it exactly in the same function.
Daniel Daranas