Victor said:
It would be, probably. Do all your classes provide the ability to
be printed out? So, why do you think that somebody else's should?
If all exceptions derived explicitly or implicitly from a single
über-exception, there would be no burden placed the developer in order to
accomplish this goal. You ask if all my classes can be printed. Well,
since a lot of what I'm currently doing is with Qt, the answer is: a lot of
them do. There is also my very first C++ interface class.
#ifndef STRINGABLE_H
#define STRINGABLE_H
#include <iosfwd>
using std:
stream;
/**
An un-universal base class
*/
namespace sth
{
class Stringable
{
public:
virtual ostream& stringify(ostream& out) const = 0;
};
inline ostream& operator<<(ostream& out, Stringable& s)
{
s.stringify(out);
return out;
}
}
#endif
But you already have that. If catch(...) clause is entered, then you
can log "undefined exception has occurred, no further information is
available".
And if everybody derives all exceptions from std::exception, the world would
be a better place. My impression of std::exception is that it was
originally intended to be used within the Standard Library. I haven't
given full consideration to the consequences of using it as the
Shah-an-Shah of exceptions. I favor making that, or something similar, a
requirement for exceptions. Of course there should be a means of changing
the default behavior through something along the lines of
std::set_unexpected().
Why can't you have a catch (std::bad_exception&) for that? Why does it
have to be in catch(...) ?
That may be an answer, but I'm not sure it would accomplish the same thing.
It's not clear to me when std::bad_exception is actually thrown. If this
means replacing the default unexpected handler to re-throw, and then catch
the exception as bad_exception, people are unlikely to use it.
It's hard to learn to use C++ exceptions correctly. This is the kind of
thing people are likely to avoid learing until they are either forced to,
or they master enough of the core language to begin investigating the
esoterica. IOW, people aren't going to use it, and if they do, they are
likely not to use it well.
Probably. But that's what catch(...) is for. Catch anything somebody
may have thrown wrong. Nothing else can be done about it. If they didn't
do anything wrong, we wouldn't need catch(...) clause.
Is that a reflection upon the developer or upon the exception facility
within C++? I really believe a few minor tweaks to the default behavior
described in the Standard would make exceptions much easier to use, and
therefor, much more commonly used. I tend to believe exceptions are a good
design mechanism which is fairly neglected in real-world C++ code.
Nobody wants to sell you anything. If you don't like a certain feature
of the language, you don't have to use it, now, do you?
If it were just me, I could control the situation. But this is the kind of
issue that impacts the usability of the language in general.
Why is it unclear? Of course it is intended. It even has virtual
functions so you could override certain behaviours.
§18.6.1 ¶1 "The class exception defines the base class for the types of
objects thrown as exceptions by C++ Standard library components, and
certain expressions, to report errors detected during program execution."
Your OS may not be implemented in C++, so it's not necessarily correct to
assume that all third-party libraries (and your OS is one of them) _can_
throw something intelligible.
Perhaps there should be a means of catching foreign exceptions.
I think you're making way too many assumptions and being inconsistent at
that. Why should _they_ provide you with "beats me" when you can do it
yourself:
try {
// whatever
..
}
catch (std::exception& e) {
cout << e.what(); // intelligible
}
catch (...) {
cout << "beats me";
}
If the default behavior were to require all exceptions be derived from
std::exception, that would be a far more obvious approach.
