I can only think of the following situations where std::exception::what() is used:
For debug purpose. In my Visual Studio to see e.what() I have to manually add it to the watch list. Isn't it better to have a member std::string (so the debugger directly shows it in the object inspector), and only include it in non-NDEBUG builds? At least they should disable what() in NDEBUG builds.
Output it, e.g. MessageBox(e.what()) or cout << e.what(). As far as I know these messages are useless for many users. For example when I try to rename a file that doesn't exist:
boost::filesystem::rename: 系统找不到指定的文件。: "D:\MyDesktop\4", "D:\MyDesktop\5"
(The Chinese words means "The system cannot find the file specified.") How can the users decrypt the mixed things? Also, it is a const char* instead of something like const platform_char*, which may have unicode problems in Windows.
Extract data from it, e.g. std::regex_match(e.what()...). I think it's a terrible idea that shows design flaws.
So where should I use std::exception::what()? Is it useless?
A programmer is supposed to derive a class from std::exception and taylor what() to the specific requirements. Then it can be very useful.
It's also useful to report something back (e.g. in plain text for logging), which is why the standard mandates a concrete std::exception::what() rather than a pure virtual function.
what() is generic in the sense that it means what you want it to mean for your own exception classes. In many cases it is used only for logging, but in other cases it may provide information that can be used to recover from an exceptional situation.
So where should I use std::exception::what()? Is it useless?
The error message of std::exception is a char* because it's supposed to be an as-simple-as-possible user-facing diagnostics message giving details on the error.
For boost::system_error (and std::system_error), you can also get the OS-level error code (for which the user-friendly message is "file not found").
Valid uses:
if you want to identify the error type, catch the specialization std::system_error or boost::system_error and perform a switch/if on the code() function (i.e. instead of running a regex on the message).
if you want to display an explanation of the error for diagnostics (logging) or user friendliness (to console/GUI) just display the error message (what()).
std::exception is a base class (i.e. it has a virtual destructor). If you implement your own exception classes, follow the same pattern as std::system_error: use an error code to easily identify an error, and create your exception's base class (std::exception, std::runtime_error or std::logic_error usually) with a text message depending on the error type.
Ultimately, the type of the error message is char* instead of std::string, wstring or your-platform-specific-char-type because it sacrifices flexibility for reliability: with a char* everybody knows how to use it, that it has no encoding (except ASCII), that it's null terminated and once allocated, it does not fail (it doesn't generate new exceptions).
Using something that could fail (in any way) when constructing an exception would be disastrous: you would fail while creating/using a diagnostics message of your error handling code.
This means you could either not throw the exception (and your application will remain in an invalid state), or throw an exception while creating an exception instance (you really don't want that as it would discard the exception you wanted to throw (hide errors) or throw an exception with a missing or corrupted error code (which could waste months of development time in various projects to track down the wrong error).
Consider this example (unnecessarily complicated, but it makes a point):
int * p = new(nothrow) int(10); // I want to throw a complicated
// string message exception
if(nullptr == p)
throw complicated_exception(std::string("error message here"));
The throw line will presumably fail: the application has so little memory available that it won't even allocate an int*, let alone a string. The result of this code is that in low memory conditions I will still get a std::out_of_memory error - one generated by std::string constructor.
std::exception is a good implementation: it provides a minimal extendable interface with a good management/restriction of failure points and it gives a good interface for extensions (such as std::system_error).
Related
I was reading this document Error Handling on the boost website.
in the point five i found this suggestion.
Blockquote
"Don't worry too much about the what() message. It's nice to have a message that a programmer stands a chance of figuring out, but you're very unlikely to be able to compose a relevant and user-comprehensible error message at the point an exception is thrown. Certainly, internationalization is beyond the scope of the exception class author. Peter Dimov makes an excellent argument that the proper use of a what() string is to serve as a key into a table of error message formatters. Now if only we could get standardized what() strings for exceptions thrown by the standard library..."
I'm wondering on how this can be realized( in a language independent way ) but i'm not so experienced.. can you make some examples ?
Thanks!
As it happens so often, "it depends" :-)
I find the what() method extremely useful in command-line applications written for advanced users (I develop scientific software). Here internationalization is not an issue as everyone understands English, and in most cases it is indeed possible to provide error messages that are meaningful to the users.
Another approach I often use is an "error class". An instance of such a class "collects" error messages and warnings while the main application runs and it prints what has been collected only upon exit. It looks like this (only the skeleton is shown to illustrate the principle):
class Errors {
public:
void add_error(const std::string& errmsg);
void add_warning(const std::string& warnmsg);
// print all errors and warnings
void print(std::ostream& out) const;
// no errors, no warnings
bool perfect() const { return (_errs.size() + _warns.size()) == 0; }
// no errors, maybe some warnings
bool ok() const { return _errs.size() == 0; }
// ...
private:
std::vector<std::string> _errs, _warns;
};
The output of what() can be saved directly in an Errors object:
try {
// ...
} catch (const std::exception& ex) {
errors.add_error(ex.what());
// ...
}
or you can generate very nice error messages, possibly internationalized, in the catch block as you see fit by translating the output of what() or by using complex exception objects that encapsulate the necessary information. Then at the end of the program you can give the user a complete list of what went wrong by invoking the print() method.
Finally, if you write software for "non-expert users", then all the caveats noted by others above apply. Basically, internationalized, easy-to-understand error messages should be presented, and only as few as possible. You should "hide" the exceptions, so to speak. No one likes popups saying "Error #x7582764 occurred, exiting" :-)
The issues of error reporting are complex. The comments on the
Boost site are mostly relevant to library code; there is no
really standard way of handling internationalization, for
example, so you cannot generate language dependent messages at
the library level (unless the library assumes one particular way
of handling it, which you generally don't want). The second
point is more general. Even neglecting internationalization, if
the exception is deep in library code, it's highly unlikely that
you could create a message which would be meaningful to a user.
In such cases, the best you can do is pass enough information up
so that the application can catch the error and generate
a meaningful message in the context of what it was doing. Thus,
instead of something like "no entry 'xyz' in table", you might
want to output "Unknown type 'xyz' when deserializing data in
file 'abc'".
I started using exceptions some weeks ago and now I wonder if there is a way to just throw a warning. This warning shouldn't force the application to exit if it isn't caught. I will give you an example in what situation I would like to use that.
There is a system that appends properties to unique ids. When I somehow try to add a property to a not yet existing id, the system should create that id internally for me, add the property to it afterwards and return the result. Of course this can't be done quietly. But since the application could stay running, I do not want to throw an exception.
How can I notify that something wasn't quite correct, but the system runs on?
Who do you want to notify? The end-user? In which case, just write a suitable message to cerr. Or better, write a wrapper function (e.g. LOG_WARNING()) to do it in a controlled manner. Or better still, use a logging framework.
But since the application could stay running, I do not want to throw an exception.
Note that an exception doesn't have to result in the application terminating. You can catch an exception higher up the stack, and handle the situation appropriately.
No, that's not possible. You can only throw and catch exceptions. If you want to be cheeky you could do
class warning : public std::exception
{
public:
warning(const std::string& msg) {}
const char* what() { return msg.c_str(); } //message of warning
private:
std::string msg;
};
Then you can:
throw warning("this is a warning");
This could be an artificially made up warning system if you want.
While there's no throwing a warning. I believe the functionality you're looking for is available from errno
You can set it to any of the standard errors or make up your own error codes. (Please document them well though.)
This could be useful if your library is meant to be used by other developers. An example of when this might be useful is with a JSON parser. JSON supports arbitrarily large numbers with arbitrary accuracy. So if internally your parser uses doubles to represent numbers if it encountered a number that it couldn't represent then it could round the number to the nearest representable number the set errno=EDOM; (argument out of range) that way, it leaves the decision up to the developers as to whether the rounding will matter. If you want to be super nice you could even add in a way to retrieve the locations of the rounds possibly even with the original text.
All of that said, this should only be used in situations where:
the warning really can be bypassed completely in some scenarios
the root source of the warning is input to the library you're writing
the in some situations the consumer of the library might care about the warning but most of the time wouldn't.
there's not a more suitable way to return the information (like a status passed by reference with an overload that doesn't require the status)
Just print a message to stderr or to your logs.
Does anyone know a opensource c++ application with a well designed/robust exception mechanism so I can get some inspiration? Most code/examples I see do questionable things like:
Throw objects with a message string as argument. Seems wrong because it marks the exception as fatal, a error message wich can be displayed to the user higher up leaves little room for client code trying to handle the exception. Even if the exception is fatal, things like diffirent locales (languages) makes formatting a message at the point of throw seem like a bad idea to me.
Use tons of different exception classes derived from a base exception class. Just feels wrong introducing a new class/type for every single thing that can go wrong (open file, read file, write file, create thread, etc...). Catching all unhandled exceptions at the highest level using the base type loses type information required to display meaningfull error messages.
Use one exception class derived from a base exception class for every component/library and give it a error code as argument to indicate the exact error. Catching with base type results in ambiguity. (Whose error code "3" did we catch? )...
Some pointers in the right direction would be welcome.
To address all three of these, I found that the best for me is to throw my own custom exception that's derived from std::runtime_error. Like this:
#include <exception>
class ChrisAException : public std::runtime_error
{
/// constructor only which passes message to base class
ChrisAException(std::string msg)
: std::runtime_error(msg)
{
}
}
It allows accepting a string, which I always put in something like the following format (assuming x negative was not a valid input and meant something calling it was in error):
#include "ChrisAException.h"
void myfunction(int x)
{
if(x < 0)
{
throw ChrisAException("myfunction(): input was negative!");
}
// rest of your function
}
For this one, keep in mind that the strings in these exceptions are more for the programmer than the end user. It's the programmer of the interface's job to display something meaningful in the locale when there's a failure. The strings in the exception can either be logged or seen at debug time (preferable!)
This way you can ultimately catch it with:
try
{
// high level code ultimately calling myfunction
}
catch(ChrisAException &cae)
{
// then log cae.what()
}
catch(std::runtime_error &e)
{
// this will also catch ChrisAException's if the above block wasn't there
}
catch(...)
{
// caught something unknown
}
I personally don't like deriving too many types of exceptions, or giving an error code. I let the string message do the reporting.
In general, I use C++ exceptions to mean "something went wrong with the program" and not to handle normal use cases. Thus, for me, a thrown exception during the algorithm execution either means "flag the user that something went wrong" or "don't tell the user" (depending on how critical that code was to what they were doing) but certainly log it and let the programmers know somehow.
I don't use C++ exceptions to handle cases that aren't essentially programming errors, e.g., some kind of incorrect logic or something being called wrong. For example, I wouldn't use C++ exceptions to handle normal program situations like an empty DVD not being in the drive for a DVD writing program. For that, I'd have explicit return code that allows the user to know whether an empty DVD was there (maybe with a dialog etc.)
Keep in mind that part of C++ exception handling is to unwind the stack up to a try-catch block. To me that means, abort what's going on in the program and clean up the stack. In the case of something like my DVD example, you shouldn't really want to unwind much of the stack. It wasn't catastrophic. You should simply let the user know and then let them try again.
But again, this is my preferred way of using C++ exceptions, based on experience and my reading. I'm open to opinions otherwise.
edit: Changed std::exception to std::runtime_error based on commenter advice.
I am designing a cross-platform application protection library to communicate with a dongle. The dongle is able to send and receive blocks of data, to create and delete directories and files inside the dongle's internal file system, etc. To put it simple, the main dongle object has methods to implement all of these functionalities. Unfortunately, any of these methods may fail. Right now I am thinking about what to do if they do :)
The most obvious solution is to return a boolean type result from all of these methods to indicate if they fail or success. However, this leads to a loss of details about the nature of an error.
The next possible solution is to return an error code, but there will be more then 30 types of errors. Also, I will need to design a separate function to convert all of these return codes to a more readable string representation.
The third solution is to return a boolean type result, but to keep an error state object in the main dongle object so it will be possible to retrieve it using GetLastError() like method. I am considering about using this one.
Now is my question. Are there any other reasonable error representation and handling patterns and what do you suggest me to use in my case?
Thanks,
Ilya
Of the options you have presented, the best is to use return codes. Typically a return code of zero indicated success, and each other return code has its own positive integral value. 30 error conditions isn't many. As you've said, you'll have to write code to translate these codes to something human-readable, but you have to do this anyway.
I would consider writing an exception hierarchy to do this instead of error codes, however. Exceptions can be more expressive than return codes, and the code can be cleaner if done properly. You would typically design your library so that there is a different exception class for each type of error return condition, each derived ultimately from std::exception. The what() method gives you a place to put the human-message building, and the type of the exception itself describes the error.
There are those who will tell you that exceptions are "only" for exceptional circumstances, like your computer caught fire, or something. This is a hotly debated assertion. I'll tell you that is nonsense. Just because it is named "exception" doesn't mean your computer has to catch fire in order to use it. Exceptions give you a lot of benefits, one of the biggest being stack unwinding. Preventing yourself from using them simply because of some arbitrary line where errors are "bad enough" is silly.
You could also try using std::exception. It allows you to say what the error is and the nature behind it.
In C++, RAII is often advocated as a superior approach to exception handling: if an exception is thrown, the stack is unwound, all the destructors are called and resources are cleaned up.
However, this presents a problem with error reporting. Say a very generic function fails, the stack is unwound to the top level and all I see in the logs would be:
Couldn't read from socket: connection reset by peer.
...or any equally generic message. This doesn't say much about the context from which the exception is thrown. Especially if I'm running something like an event queue processing loop.
Of course I could wrap every call to socket reads with a try/catch block, catch the exception, construct a new one with more detailed context information and re-throw it, but it defeats the purpose of having RAII, and is slowly but surely becoming worse than handling return error codes.
What's a better way for detailed for error reporting in standard C++? I'm also open to suggestions involving Boost.
As James McNellis suggested here, there is a really neat trick involving a guard object and the std::uncaught_exception facility.
The idea is to write code like this:
void function(int a, int b)
{
STACK_TRACE("function") << "a: " << a << ", b: " << b;
// do anything
}
And have the message logged only in case an exception is actually thrown.
The class is very simple:
class StackTrace: boost::noncopyable // doesn't make sense to copy it
{
public:
StackTrace(): mStream() {}
~StackTrace()
{
if (std::uncaught_exception())
{
std::cout << mStream.str() << '\n';
}
}
std::ostream& set(char const* function, char const* file, unsigned int line)
{
return mStream << file << "#" << line << " - " << function << " - ";
}
private:
std::ostringstream mStream;
};
#define STACK_TRACE(func) \
StackTrace ReallyUnwieldyName; \
ReallyUnwieldyName.set(func, __FILE__, __LINE__)
One can use __PRETTY_FUNC__ or equivalent to avoid naming the function, but I have found in practice that it was too mangled / verbose for my own taste.
Note that you need a named object if you wish it to live till the end of the scope, which is the purpose here. We could think of tricky ways to generate a unique identifier, but I have never needed it, even when protecting narrower scope within a function, the rules of name hiding play in our favor.
If you combine this with an ExceptionManager (something where exceptions thrown register themselves), then you can get a reference to the latest exception and in case of logging you can rather decide to setup your stack within the exception itself. So that it's printed by what and ignored if the exception is discarded.
This is a matter of taste.
Note that in the presence of ExceptionManager you must remain aware that not all exceptions can be retrieved with it --> only the ones you have crafted yourself. As such you still need a measure of protection against std::out_of_range and 3rd party exceptions.
Say a very generic function fails, the stack is unwound to the top level and all I see in the logs would be [...]
What's a better way for detailed for error reporting in standard C++?
Error handling isn't local to a class or library - it is a application level concern.
Best I can answer you question is that the error reporting should be always implemented by looking first and foremost at the error handling. (And the error handling also including the handling of the error by the user.) Error handling is the decision making about what has to be done about the error.
That is one of the reasons why error reporting is an application level concern and strongly depends on the application workflow. In one application the "connection reset by peer" is a fatal error - in another it is a norm of life, error should be silently handled, connection should be reestablished and pending operation retried.
Thus the approach you mention - catch the exception, construct a new one with more detailed context information and re-throw it - is a valid one too: it is up to the top level application logic (or even user configuration) to decide whether the error is really an error or some special (re)action has to taken upon the condition.
What you have encountered is one of the weaknesses of so called out-of-line error handling (aka exceptions). And I'm not aware of any way to do it better. Exceptions create a secondary code path in the application and if error reporting is vital the design of the secondary code path has to treated just like the main code path.
Obvious alternative to the out-of-line error handling is the in-line error handling - good ol' return codes and log messages on the error conditions. That allows for a trick where application saves all low-severity log messages into internal (circular) buffer (of fixed or configurable size) and dumps them into the log only if high-severity error happens. This way more context information is available and different layers of application do not have to be actively aware of each other. That is also standard (and sometimes literally "standard" - mandated by law) way of error reporting in application fields like safety and mission critical software, were one is not allowed to miss errors.
I've never actually done this, but you could roll your own "stacktrace":
struct ErrorMessage {
const char *s;
ErrorMessage(const char *s) : msg(s) {}
~ErrorMessage() { if (s) std::cout << s << "\n"; }
void done() { s = 0; }
};
void someOperation() {
ErrorMessage msg("Doing the first bit");
// do various stuff that could throw
msg = "Doing the second bit";
// do more stuff that could throw
msg.done();
}
You can have several levels of this (although not necessarily use it at every level):
void handleFoo() {
ErrorMessage msg("Handling foo event");
someOperation();
msg.done();
}
And add more constructors and members:
void handleBar(const BarEvent &b) {
ErrorMessage msg(std::stringstream("Handling bar event ") << b.id);
someOperation();
msg.done();
}
And you needn't write the messages to std::cout. It could be to some logging object, and the object could queue them, and not actually output them to the log unless the catch site tells it to. That way, if you catch an exception that doesn't warrant logging, nothing is written.
It's not pretty, but it's prettier than try/catch/throw or checking return values. And if you forget to call done on success (for example if your function has multiple returns and you miss one), then you will at least see your mistake in the logs, unlike a resource leak.
[Edit: oh, and with a suitable macro you can store __FILE__ and __LINE__ in the ErrorMessage.]
You could add a call stack to your exception. I'm not sure how good this works for release builds but works like a charm with debug. You could do this in the constructor of your exception (to encapsulate it). See here for a starting point. This is possible as well on Linux - eventhough I dont remember how exactly.
I use RAII and exceptions and just have various unit-test-like assert statements throughout the code - if they fail, the the stack unwinds to where I can catch and handle them.
#define APP_ASSERT_MSG(Class,Assertion,szDescription) \
if ( !(Assertion) ) \
{ \
throw Class(__LINE__,__FILE__,szDescription); \
}
For most of my particular use case, all I care about is logging debug information, so my exception has the file and line number in it along with an error message (message is optional as I have an assert without it as well). You could easily add FUNCTION or an error code of some type for better handling.
I can then use it like this:
int nRet = download_file(...);
APP_ASSERT_MSG(DownloadException == ERR_OK, "Download failed");
This makes error handling and reporting much easier.
For really nasty debugging, I used GCC's function instrumentation to keep a trace list of what's going on. It works well, but slows down the app quite a bit.
What I do regularly, FWIW, is not use exceptions, but rather explicit error handling in a standard format (ie: using a macro). For example:
result = DoSomething();
CHECK_RESULT_AND_RETURN_ON_ERROR( result );
Now, obviously, this has many limitations design-wise:
Your return codes may need to be somewhat uniform
Code is cluttered with macros
You may need many macros for various check conditions
The upside, though, is as Dummy00001 said: you can effectively generate a stack trace on demand in the event of a serious error, by simply caching the results. I also use this paradigm to log all unexpected error conditions, so I can adjust the code later to handle unexpected conditions which occur "in the wild".
That's my 2c.
Here's how I handle error reporting in my libraries (this may or may not suit your situation).
First, as part of your design you want a "core" or "system" library that all this common logic will sit in. All you other libraries will then link to the core and use its error reporting APIs, so your whole system has a single compact chunk of logic for handling this mess.
Inside the core, provide a set of logging MACROS such as "LogWarning" and "LogFatal" with documented behavior and expected usage- for example, LogFatal should trigger a hard abort of the process but anything lower than "LogError" is simply advisory (does nothing). The macros can provide a "printf" interface that automatically appends the "LINE", "FILE", and "FUNC" macros as arguments to the underlying singleton object that handles your error reporting.
For the object itself I'll defer to you. However, you want public APIs that configure your "drains"- e.g. log to stderr, log to logfile, log to MS Services log, etc. You also want the underlying singleton to be thread safe, re-entrant where possible, and very robust.
With this system, you can make "exception reporting" ONE MORE DRAIN TYPE. Just add an internal API to that error manager object that packages your logged message as an exception, then throws it. Users can then enable AND DISABLE exceptions-on-error behavior in your code with ONE LINE in their apps. You can put try-catches around 3rd party or system code in you libraries that then calls a "Log..." macro in the catch clauses to enable clean re-throw behavior (with certain platforms and compiler options you can even catch things like segfaults using this).