|
Boost : |
From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-06-29 09:10:08
In message <00bd01bfe1ce$bb48db90$3e116e97_at_[hidden]>, Ed Brey
<brey_at_[hidden]> writes
>From: "Kevlin Henney" <kevlin_at_[hidden]>
>> I would contend that this leads to three ways of using the cast rather
>> than two:
>>
>> (1) Use it so that it throws on failure.
>> (2) Use it so that it does nothing on failure and defaults the value.
>> (3) Use it so that it returns a status on failure.
>>
>> I personally would use (1) if I wanted to know about failure and (2) if
>> I didn't, which makes (3) seem a little like gold plating.
>
>I agree with your take on (3), other than when conversion failures are not
>exceptional cases. One problem is that if failures are frequent, exceptions
>may be too slow. Also, there is the issue with how easy/cumbersome the code
>is to write. A previous post [1] went into this in more detail, but the
>summary is that try blocks work well when there are many conversions and
>possibly other operations for which failure can be handled uniformly,
>whereas if there is unique recovery action for each potential failed
>conversion, then having the status returned is quite convenient.
How about an evolutionary approach? Address (1) and (2) now, and gauge
the subsequent usability etc of the cast. This can then be fed into the
next version, including consideration of (3).
____________________________________________________________
Kevlin Henney phone: +44 117 942 2990
Curbralan Ltd mobile: +44 7801 073 508
kevlin_at_[hidden] fax: +44 870 052 2289
____________________________________________________________
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk