Re: [boost] Re: Re: Sockets!

From: Peter Dimov (pdimov_at_[hidden])
Date: 2003-10-30 07:03:26

Beman Dawes wrote:
> At 03:22 PM 10/27/2003, Jessie Hernandez wrote:
>  >...
>  >Well, I personally prefer a "large" socket exception hierarchy. This
> makes
>  >it very easy to catch specific exceptions and provides better error
>  >messages. With the current STL file classes, you may get errors
>  such as >"ios_base::failbit set!" (since there is only one exception
>  class, >ios_base::failure). This doesn't tell me why the failure
> happened (does
> the
>  >user have permissions to the file, etc.?) I'd rather have classes
>  such as >socket_base::connection_refused, etc., which have their
>  what() methods >overloaded to print out more specific messages.
>
> FWIW, the LWG just looked at a similar situation for regular
> expressions.
> The solution they prefer is for a single exception class for the
> library, but adding a member function which will return a code which
> identifies the specific reason for the failure. This member function
> is in addition to what().

FWIW, following that LWG precedent in all cases is dead wrong. ;-)

If code needs to determine the specific reason for the failure, the
specifity needs to be encoded in the exception type.

try
{
    f();
}
catch(reason_I_care_about const & x)
{
    // appropriate action
}

The alternative forced upon users is

try
{
    f();
}
catch(general_failure const & x)
{
    // who is that general failure character?
    if(x.code() == reason_I_care_about)
    {
        // appropriate action
    }
    else
    {
        // throw; // not one of ours
    }
}

which breaks the "never catch if you don't know how to handle" rule.

Alex T will have something to add I'm sure, it also breaks his beloved two
phase model. ;-)