Re: [boost] Exception lib?

From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2006-07-05 14:07:04

On 7/6/06, Emil Dotchevski <emildotchevski_at_[hidden]> wrote:
>
> You need the dynamic_cast, because all you have is a read_error pointer, and
> you need an exception_info pointer *if* it is available. For one reason or
> another, the program could throw a "naked" read_error object (as opposed to
> using throw failed<read_error>()) and in this case you will not have an
> exception_info sub-object in the exception.
>
> The reason why I have not hidden the dynamic_cast in a function
> get_exception_info() is that the only implementation possible is through a
> dynamic_cast, so why bother.
>

How about using preprocessor macro's to hide this? Something like a
BOOST_EXCEPTION_INFO(exception_reference, exception_info_handle) which
abstracts the fact that you use dynamic_cast<> to return an
exception_info_handle ? The following would look "cleaner":

try {
} catch (read_error & e) {
  BOOST_EXCEPTION_INFO(e, info);
 if (info) {
    // use the info object, otherwise this doesn't get executed
  }

  //.. handle exception normally
}

A templates only approach would be something like:

try {
} catch (read_error & e) {
  extract_info<read_error> info(e);
  if (info) {
    // if e was a failed<> wrapped exception, info is defined
    // and can be accessed -- therefore this block will be executed
  }

  // deal with exception accordingly
}

This way, if in case there's a different way of accessing the
exception info subobject (or internal reference, or some other
methodology in case the design changes in the future), there's an
interface to abstract the details of extracting the information object
from the more important implementation.

It's probably a personal issue against the use of dynamic_cast<> or
static_cast<> and even const_cast<> because IMHO it makes code
terribly un-readable and even seem "hackish". It's my personal opinion
that whenever you need to resort to casting in client code, then that
means the design of the solution isn't as elegant or as well thought
out as it could be.

-- 
Dean Michael C. Berris
C/C++ Software Architect
Orange and Bronze Software Labs
http://3w-agility.blogspot.com/
http://cplusplus-soup.blogspot.com/
Mobile: [phone]
Email: dean [at] orangeandbronze [dot] com