Re: [boost] [RFC] string inserter/extractor "q u o t i n g"

Subject: Re: [boost] [RFC] string inserter/extractor "q u o t i n g"
From: Eric Niebler (eric_at_[hidden])
Date: 2010-06-23 11:06:09

On 6/23/2010 11:01 AM, Eric Niebler wrote:
> On 6/23/2010 6:12 AM, Daniel James wrote:
>> On 23 June 2010 03:49, Rob Stewart <robertstewart_at_[hidden]> wrote:
>>> I quickly chose to throw std::logic_error from unquoted() when it fails to
>>> find a closing delimiter.  There may well be a better approach; feel free to
>>> suggest alternatives.
>>
>> You should inherit from std::runtime_error, since that would be
>> usually caused by bad input rather than programmer error.
> 
> Bad input can be a programmer error too. Here's how you decide:
> 
> - Decide if passing a malformed string is a violation of unquote's
> preconditions.
> - If it is, throw something derived from logic_error.

I mean, assert, not throw. Sigh, bitten by C++'s weird exception
hierarchy again. logic_error is useless because it derives from
std::exception, which people catch all over the place. A precondition
violation is not recoverable.

> - If not, handle it gracefully or, if you cannot, throw something
> derived from runtime_error.
> 
> Users can (in theory) check that the string is well-formed before
> calling unquote, but to do so they would essentially have to implement
> unquote themselves. So making it a precondition that the input is
> well-formed seems onerous in this case. I would not make it a
> precondition; instead, I would accept it as valid input and document that.
> 
> For valid input, I would prefer if unquote found a way to muddle through
> and do something reasonable. Throwing an exception when a trailing quote
> is missing seems like smacking someone's hand when they forgot to say
> "mother may I?" Why not just accept it? And document that fact! If the
> string is malformed in a way that you really can't muddle on, then throw
> something derived from runtime_error.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com