exceptions with namespace hierarchy, what(), why(), line(), file()

[KarlisRepsons]

Hi again!

This post seeks well explained opinions about the further
outlined approach of using exceptions. It's presumed that
nothing more than just the type of exception may be used to
influence the further code execution in a program, yet for
debugging purposes it might be helpful to have code doing
some checking and throwing informative exceptions. This
could be used by iterators, access functions etc.

Sort of this:

if (mMap.find(keyRef) == mMap.end())
throw EXCN::LOGIC::out_of_range(__FILE__, __LINE__, why);

Extensible exception hierarchy:

namespace EXCN
{
  using namespace EXCN_impl;
  typedef EXCN_impl::base<ST> base;
  typedef excn_template<ST,cs_logic::logic> logic;

  namespace LOGIC
  {
    typedef excn_subtemplate<
      ST,logic,cs_logic::out_of_range>
      out_of_range;
  }
}

Adding a new exception takes at least declaring a global
char const what_of_the_new_exception[] and adding it to the
above hierarchy.

what() of an excn_template or excn_subtemplate gives just
something like "logic > out_of_range", while why() may
provide a detailed description of the cause. + file() and
line() functions.

Maybe it's just a choice between something like a mystical
segfault and an ugly, but informative exception:
catch (EXCN::base &e) { e.report_cerr(); exit(1); }

[kbw]

I can't see what your exception hierarchy gives that the existing standard exceptions doesn't.

If you want Pythonesq debugging in debug C++ builds, you could probably get away with a macro that builds a reporting string that uses __FILE__ etc for debug. It would need to be a macro because it needs to be evaluated in place.

Additionally, if your error reporting hierarchy gets too clever, you run the risk of reporting misleading messages in the same way that early STL implementations tended to show seemingly unrelated messages on encountering a syntax error.

[KarlisRepsons]

Perhaps usability for debugging purposes? If exceptions are
for error handling, why not make them help finding out the
causes of errors? I mean, give line nr., file name and throw
them along with automatically generated what(). why() is
actually more like std::exception::what(). Then catch
somewhere and don't clutter up code with macros or some
direct error output code... Besides, it seems easier to add
a new exception by just giving an externally linked string
literal as a template parameter for it's what() and adding a
typedef... (rather than making a new class with a new what()
method for overriding) (take into account that what()
returns string to indicate exception hierarchy and name!)

(I switch between two compilation modes -- normally I just
leave that debug info in, but can make a bare exception of
the appropriate type be thrown)