Re: [boost] Re: Re: Re: Re: Re: Sockets!

From: Peter Dimov (pdimov_at_[hidden])
Date: 2003-10-31 07:49:47

Jessie Hernandez wrote:
> "Peter Dimov" <pdimov_at_[hidden]> wrote in message
> news:008901c39f30$302d7d40$1d00a8c0_at_pdimov2...
>> Jessie Hernandez wrote:
>>
>> [...]
>>
>>> For these reasons, I think providing a minimal number of exception
>>> classes is the middle-ground. I don't consider it a "virtue", but I
>>> think this change will please most users.
>>
>> In other words, you will deliberately make your design worse because
>> this "will please most users" (an unproven assertion).
>>
>> If you have many exception classes, people that don't feel
>> comfortable with them (assuming that there are such people; it is
>> somewhat insulting to think of your users as so deficient) can still
>> use the appropriate intermediate exception classes exactly as if
>> these classes were the only exceptions provided.
>>
>
> I don't see reducing the amount of exception classes as "making the
> design worse". Also, my comments were not meant to be insulting to
> anyone (forgive me if they could have been interpreted this way). On
> the contrary, all I want to do is gather opinions from everyone to
> see where I should put future efforts in the library.

Understood. I apologize for the unnecessary harshness. I'll try to explain a
bit more calmly what provoked me. I'll start with the following, taken out
of order:

> I am trying to do the same with the sockets library. If the majority
> want less exception classes, then I will reduce it. If they want
> more, then I'll add more. My opinion on this matter may not be the
> same as the majority's opinion, but the fact remains that the opinion
> of the majority is what counts, and I don't mind making these types
> of changes.

No. The opinion of the majority most definitely does not count, if the
majority is wrong.

Approximating "right" by polling and taking the opinion of the majority
should only be applied in cases where objective measurements cannot provide
a (socially acceptable) answer. This is not the case here. There are several
fairly simple rules of thumb that can be used; most of them are best stated
in a negative form, i.e. what not to do.

* Don't force users to catch something that they do not need to handle.
* Don't force users to write switch statements if a chain of catch handlers
will do.
* Don't force users to write a chain of catch handlers in situations where a
single catch will do better.
* Don't use unproven assertions about public/LWG opinion as justification
for the design.
* In case of conflicting priorities, do tailor the design for what the
majority of users _do_. Don't be affected by what they _say_ they would do,
could do, or what they like. Don't be affected by what they do but need not
(the "unpythonic" rule ;-) ).

That said:

> I don't see reducing the amount of exception classes as "making the
> design worse".

> Also, FWIW, Java's java.net package only has 11 exception classes,
> and most of these are "generic" (such as BindException and
> ConnectException).

No problem with that. I only oppose the "LWG likes X", "the majority likes
Y", "people are comfortable with Z", "we should minimize the number of
exception classes" attitude, not any particular design. If the best design
has 11 classes, then so be it.

> Consider the string_algo review that's currently going on: there has
> been much debate on what to name the in-place and copy versions of the
> algorithms. IIRC, there were several proposals, such as "trim(str)",
> "s2=trim_copy(s1)", "trim(inplace(str))", "s2=trimmed(s1)", etc. The
> author of the library might prefer having "trim" and "trim_copy",
> e.g., but what if the majority of users want to have "trim" and
> "trimmed"? Then it will have these names, though the author might not
> specifically agree with them.

For naming issues, democracy may be an acceptable approach, in cases where
no information is available for scientific methods to be able to provide a
satisfactory answer. ;-) And, of course, names do not affect the design,
only usability for some limited initial transition period.