Thread: The opposite of noexcept

[Edit: The title of this thread should have been "The opposite of noexcept". Sorry about that.] (fixed: Salem)


I have a variety of Die()-type routines that I use for stack tracing of exceptions and so forth. Typical usage would be something like

Code:

int myfunc()
{
  if (condition)
  {
    return 0;
  }
  else
  {
    Die("error message", HERE);
  }
}

Die() builds an exception object from the error message, and from the information in HERE (which is just a macro that expands to __LINE__, __FILE__, __PRETTY_FUNCTION__). It then throws the exception.

There is of course a problem with this setup. Since myfunc() and Die() are defined in different translation units, the compiler has no way of knowing that Die() always throws an exception. Accordingly (since we're using the -Wall option) it will grumble that the else block of myfunc() doesn't return an int value.

There are a few simple ways of addressing this, such as:

1. adding a "throw" statement after Die() in the else block;
2. putting a default return value at the end of myfunc();
3. using -Wno-return-value in the compiler options list.

At first, I didn't like options 1 and 2. So I used option 3 instead. Boy, did I end up regretting that one.

So now my code is now full of dummy throw and return statements that don't actually do anything (and could act as red herrings during debugging), but which have to be there to keep the compiler from throwing tons of warnings about things that can't happen.

Is there any way of letting the compiler know that it doesn't need to worry about missing return values from logic branches that contain calls to Die()?

Equivalently, is there any way of letting the compiler know that Die() always throws an exception? This would be the same as having an "alwaysexcept" specifier, the opposite of "noexcept".

There is no "always throws" specifier to my knowledge, so I'd just go with 2. What's the problem with one little dummy return statement at the end of the functions?
Alternatively, you can try putting Die in a header as an inline function, allowing the compiler to see that it always throws.

I suggest you don't use that - it's non-portable between compilers.

Why not re-structure it?

Code:

int myfunc()
{
  if (!condition)
  {
    Die("error message", HERE);
  }
  return 0;
}

This is effectively the common idiom of checking for pre-condition violations and returning (or throwing an exception) early, and then when one is certain that the pre-conditions have been satisfied, performing the normal work and returning.

Originally Posted by Grumpulus

...found something that is pretty much exactly what I need: the [[noreturn]] attribute.

Originally Posted by Elysia

I suggest you don't use that - it's non-portable between compilers.

Compilers may not have support for it yet, but isn't that the new standard-compliant (C++11) way to do it? Clang should support it, as should GCC 4.8 and above. MS Visual C++ does not, and there is no indication that they ever will, as they have their own attribute syntax.

Looking at it now, it is true that it is actually standard. So in the future, all compiler may actually support it. But for now, it's not portable between between VC++ and g++/clang. I'm guessing VC++ will support it sometime in the future.

Originally Posted by laserlight

Why not re-structure it?

Code:

int myfunc()
{
  if (!condition)
  {
    Die("error message", HERE);
  }
  return 0;
}

This is effectively the common idiom of checking for pre-condition violations and returning (or throwing an exception) early, and then when one is certain that the pre-conditions have been satisfied, performing the normal work and returning.

I actually have another function called DieIf(bool condition, char const* message) that does exactly this.

(Unfortunately, DieIf() isn't very helpful if the message needs to include more information than a string literal. I did write a DieIf(bool condition, std::string const& message) for that purpose, but then realized that the std::string gets constructed even when the condition is false -- not great for optimization!)

Basically this is just a convenience issue. As it happens, pretty much everybody in my industry uses GCC, and this particular software is intended for in-house use only, so I'm probably safe using the attribute -- provided of course that documentation of this little caveat appears in the header file where the function is defined.

My expectation is that this attribute will find its way into other compilers in short order. It's just too useful not to be there.

Thanks for the feedback everyone.

Originally Posted by Grumpulus

I actually have another function called DieIf(bool condition, char const* message) that does exactly this.

(Unfortunately, DieIf() isn't very helpful if the message needs to include more information than a string literal. I did write a DieIf(bool condition, std::string message) for that purpose, but then realized that the std::string gets constructed even when the condition is false -- not great for optimization!)

I am suggesting a restructure of the code that calls Die, not a restructure of Die itself or to change the parameters of Die into DieIf. Consequently, your "isn't very helpful" point and your "not great for optimization" points are not relevant: you can arrange for Die to include whatever other info is needed, and the std::string will only get constructor when the condition is false (or true, as the case may be).