C++ "standard messages"

Hello,

I'm looking to satisfy a curiosity of mine. As a preface, Consider the following code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
#include <iostream>
#include <stdexcept>
#include <vector>

int main() {

	std::vector<int> vector(10);

	try {
		vector.at(20) = 1;
	}
	catch (const std::out_of_range& error) {
		std::cerr << error.what() << std::endl;
	}

	return 0;
}


The <stdexcept> header contains the standard exceptions, which inherit from std::exception. Each of them has a unique generic message, which is achieved by overriding the what member function.
For example: std::out_of_range is a standard exception, whose what returns "invalid vector<T> subscript" when invoked, like in my example above.

Standard exceptions are very handy for this reason. The standard gives us these generic messages to use in our code, so that we don't have to roll with our own implementations (since these exceptions can be common occurrences).

Question: Does there exist, within the standard, a list of generic messages to be used for trivial, not-exceptional errors? For example, if the user is prompted to enter an integer, but enters something else ("Please enter an integer:\t" / "Try again:\t")? This is purely in the interest of keeping my code as generic as possible.
I looked into the message catalogs found in <locale>, but I'm not sure that's what I'm after. Any help is appreciated.
Last edited on
You are asking two questions, really:

1. Is it okay to use exceptions for flow control?

- No. Only in the sense that flow may be predicated on whether or not a specific error occurs.

2. What should exception messages look like?

- There is no catalogue, but exception messages typically follow a pattern.
- My exceptions typically look like "typename: precondition violation x".
  For library code I may also include the line number where the error is generated.

For your particular example, most C++ folk will dislike the idea that an exception controls interactive input validation. Rather, your code should only throw if something it cannot recover from has happened.

That is:
- functions that cannot handle an error that prevents their correct function should throw
- code using said functions can chose to handle the error or not

Hope this helps.
Topic archived. No new replies allowed.