How to silence 'The last statement should return a value' warning?

Question

Sun Studio 12.1 prints the warning

Warning: The last statement should return a value.

frequently for functions like that:

int f()
{
  /* some code that may return */

  // if we end up here, something is broken
  throw std::runtime_error("Error ...");
}

It is perfectly clear that we do not need a return value at the end of the function. I hesitate to insert something like

// Silence a compiler warning
return 42;

at the end of such a function, since it is dead code anyway. For more complicated return types, it might actually be difficult to construct a 'sensible' bogus value.

What is the recommended way to silence such a warning?

Is it precisely the last line of the function that throws? Is that throw statement free of the scope of any conditional block of logic? — razlebe, Apr 12 '11 at 15:24
my bad, I actually have Sun Studio 12.1. I always get confused by the version numbers it reports. I will update the question. — lytenyn, Apr 12 '11 at 15:26
never happened with gcc... do Sun have their own c++ compiler? — davka, Apr 12 '11 at 16:02
@davka Yes, Sun cc for C and CC for C++. g++ handles this case properly. — Mark B, Apr 12 '11 at 16:09

Mark B · Accepted Answer · 2011-04-12T16:10:29.583

Can you reorganize the code in the function in such a way (hopefully more logical as well) that the normal path happens at the end of the function so that a return can be used, and the exceptional path happens earlier, NOT as the last statement?

EDIT: If reorganizing the function really doesn't make sense, you can always just put a dummy return 0; with a comment. It's better to squelch the warning that way than more globally.

If you really want to quiet the warning permanently, you can use #pragma error_messages (off, wnoretvalue) but note that the warning really is useful most of the time so I absolutely don't suggest turning it off. You can use the on version of the pragma to re-enable the warning after the function, but the compiler will still emit the warning if your function is ever inlined. If you put the function in its own source file and use the pragma that should shush the warning relatively safely though, since it can't affect other translation units.

Another really wacky possibility is to switch to g++. Unless you're compiling for SPARC g++ may actually generate better code than Sun studio.

+1 I agree with this answer, if you are throwing an exception as the last line of a function, you should be able to reorganize the method to not do that. — Andy White, Apr 12 '11 at 15:24
you are probably right about that in general, but actually the code is pretty sensible that way and I am not sure how to handle this any better the way you suggest. — lytenyn, Apr 12 '11 at 15:29

score 3 · Answer 2 · answered Apr 12 '11 at 15:24

3

I find it a perfect spot for abort(). You should never end there, according to you, so something like:

UNREACHABLE("message")

which expands into:

#ifdef NDEBUG
  #define UNREACHABLE(Message_) abort();
#else
  #define UNREACHABLE(Message_) assert(0 && Message_);
#endif

Looks appropriate

answered Apr 12 '11 at 15:24

Matthieu M.

287,565
48
449
722

But you'd still get a warning about not returning a value? – Steve Folly Apr 12 '11 at 15:41
Oh, +1 for the `0 && Message_` assertion failure. I've also used `!Message_` before. – Steve Folly Apr 12 '11 at 15:42
I like this better than returning something arbitrary, thank you. – lytenyn Apr 12 '11 at 15:43
@Steve Folly: No, this silences the warning. – lytenyn Apr 12 '11 at 15:43
@Steve Folly: normally the compiler should be smart enough to figure that the flow will end abruptly and the function never returns. – Matthieu M. Apr 12 '11 at 15:46
@Matthieu M.: On the other hand, the compiler should also be smart enough to see that the flow also ends abruptly at `throw`. – lytenyn Apr 12 '11 at 15:49
@lytenyn: Ah sorry, I thought that `throw` was how you were silencing the compiler and I just proposed a (hardened) replacement that would be able to work around `catch(...)` statements. – Matthieu M. Apr 12 '11 at 15:59

score 2 · Answer 3 · answered Apr 12 '11 at 15:20

2

Since you know the exception will be systematically called, why don't you simply return a 0?

answered Apr 12 '11 at 15:20

Charles Brunet

21,797
24
83
124

I must admit that I do not understand that answer. I somehow just consider returning 0 or 42 to be 'ugly'. What do you mean by 'systematically called'? – lytenyn Apr 12 '11 at 15:30
@lytenyn I mean the exception will always be thrown and the return will never be called. – Charles Brunet Apr 12 '11 at 15:33
well no, typically, the function returns something. It's just that if all possible paths are exhausted, the function throws an exception. – lytenyn Apr 12 '11 at 15:36
That's what i'm saying. It will either return something you want, or thrown the exception, so it will never call the last return, so the value there doesn't matter. – Charles Brunet Apr 12 '11 at 15:40
You are right. My question was whether there is a better way than returning an arbitrary value which I consider a bit ugly. – lytenyn Apr 12 '11 at 15:42

score 1 · Answer 4 · answered Apr 12 '11 at 16:37

Perhaps encapsulate the contents in a do { } while (false); construct:

int my_function()
{
  int result = DEFAULT_VALUE;
  do
  {
     result = /*...*/
     // Whatever
     if (error)
     {
       throw std::runtime_error("Error ...");
     }
   } while (false);
   return result;
}

The idea is for normal operation to set the result value then let the execution flow to the end or use a break to jump to the return statement.

score 0 · Answer 5 · answered Apr 12 '11 at 15:39

0

I don't know of a "recommended" way to deal with it, but to answer your question about coping with more complex types, what about:

ComplexType foo()
{
    ...
    throw std::runtime( "Error..." );
    return *(ComplexType*)(0);
}

This would then work with any return type. I realise it looks evil, but its there just to silence the warning. As you say, this code will never be executed, and it may even be optimised out.

answered Apr 12 '11 at 15:39

Steve Folly

8,327
9
52
63

I can't say I agree with adding potentially undefined code just to silence a warning. – Mark B Apr 12 '11 at 15:52

How to silence 'The last statement should return a value' warning?

5 Answers5

Linked