Is the `std::exception`, in its current form, redundant?

Question

Usually, when I want to create my own exception, I inherit from std::exception or std::runtime_error.

Is there anything that stops me from creating my own empty "tag-class"?

class out_of_bounds_access {}; // or:
class memory_leak {};

and throw just that?
After all, mostly, it's the class-name that carries information about what went wrong not the members of the exception class.

Ok, so I assumed this is a bad idea, but why? Why is this a bad idea?

P.S. I know there are cases in which "custom-made" exceptions carry information that latter is used to determine the correct approach to solve the problem...
However, if you think about it, cases like that can, very often (not always, but often), be re-done to throw & catch multiple different tag-classes instead of just a single one (with "content").

Answer 1

No, nothing stops you from doing this.

However, some code that wants to catch "any exception" will catch const std::exception&, and if your exception type doesn't derive from std::exception then that won't work.

Sure, we can catch ... instead but that's, in my experience, used as a last-ditch "blunt instrument" for avoiding termination due to uncaught exceptions, and can't tell you anything about the exception itself.

Boost exceptions don't derive from std::exception and it's really annoying.

Why not just make all the exceptions part of this standard hierarchy?

If you don't intend to ever let your exception types make get all the way to the top, then there may not be a practical problem here. But, why take the chance? You lose nothing by adding : std::runtime_error or somesuch, and the text string that you'll pass to the base is useful information for the diagnosing programmer.