Am 14.03.2014 10:57, schrieb Robert Klemme:
> On Thu, Mar 13, 2014 at 10:35 PM,  <sto.mar / web.de> wrote:
>> Am 11.03.2014 11:06, schrieb Robert Klemme:
[...]
>>> No. There is already one standard solution.  Best is to just use
>>> Integer and handle the exception.
>>>
>>> size = Integer(gets)
>>
>> "Best" is a matter of taste...
> 
> I'd say it's a matter of values: your values determine what you
> consider better or worse. But of course there is a certain factor of
> subjectivity here. OTOH there are best practices in the industry. :-)

I did not want to start a discussion on pros and cons of both
versions, that's why I said matter of taste :)
There is also "best practice" of not using exceptions for flow control.
Again opinions diverge.

[...]
> Usually it's better to execute an operation and deal with failure than
> to try to determine whether it will work, execute it - and still have
> to deal with failure.  This is especially true for situations where
> conditions can change between the check and the operation which allow
> the operation still to fail. Typical example is: you check network
> connectivity (e.g. to a database) and then do the actual connection.
> You always have to deal with potential connection failures, even if
> the check succeeded.  So you are making the code more complicated and
> do not gain anything.

Agreed, but that doesn't really apply here.
The "integerness" of a string is not likely to change :)

>>> You can even catch in line if you really need to use this in a branch condition
>>>
>>> size = Integer(gets) rescue nil
>>
>> I strongly disagree, you should *never* do that.
>>
>> Consider e.g. a stupid typo in the code, like:
>>
>>   size = Integer(getss)  rescue nil
>>
>> This would **not** raise any exception, but you certainly would
>> want it to raise one (NameError).
> 
> That will be apparent quite soon during testing. You'll also get
> another exception when using the object as an integer.

The problem I wanted to point out is that with "rescue nil" you could
not distinguish between 1) bad user input and 2) any other problem.
For more intricate situations that might not be so easily detected
during tests, e.g. timeouts from a network connection. Happy debugging!

"rescue nil" is widely considered to be a code smell.

Regards,
Marcus


-- 
GitHub: https://github.com/stomar/
PGP:    0x6B3A101A