On 02/24/2017 01:57 PM, Josef Reidinger wrote:
> On Fri, 24 Feb 2017 13:51:42 +0100
> Arvin Schnell <[email protected]> wrote:
>
>> On Fri, Feb 24, 2017 at 01:34:31PM +0100, Josef Reidinger wrote:
>>> On Fri, 24 Feb 2017 10:58:19 +0100
>>> Arvin Schnell <[email protected]> wrote:
>>>
>>>> On Fri, Feb 24, 2017 at 10:37:24AM +0100, Josef Reidinger wrote:
>>>>
>>>>> Nil instead of exceptions
>>>>> -------------------------
>>>>>
>>>>> make sense for me, another option that make sense for me is
>>>>> NullObject, that allows some introspection and e.g. better
>>>>> writting to log.
>>>>
>>>> Exceptions come with introspection and logging.
>>>>
>>>> ciao Arvin
>>>>
>>>
>>> We also discussed it in past and now with seeing that I need to
>>> rescue around every call for valid storage setup in bootloader, I
>>> found it even more annoying.
>>
>> You don't have to. E.g. instead of calling
>> 'partition.get_filesystem()' and catching an exception you can
>> also query 'partition.has_filesystem()' beforehand. The
>> programming style is up to you.
>>
>> ciao Arvin
>>
>
> OK, I do not know about it.
>
> Ancor what was reason to not use this kind in bootloader and
> yast-storage-ng instead of bunch of rescues?
The reason is that some of those methods (like has_partition_table) were
not there initially, they were added on demand.
Defining an extra method for every relationship we want to have in our
model is just duplicating the existing and standard Ruby mechanism for
that (returning nil).
Assume there is always a "has_xxx" method to do the check in advance.
There are still many situations in which that is way less practical than
returning nil.
For example, something as simple as this with the typical Ruby behavior
(returning nil)
def compare_fs(partition1, partition2)
partition1.filesystem == partition2.filesystem
end
With the current approach of rescuing exceptions or using the check
method in advance (assuming that particular check method exist).
def compare_fs(partition1, partition2)
if partition1.has_filesystem
if partition2.has_filesystem
partition1.filesystem == partition2.filesystem
else
false
end
else
!partition2.has_filesystem
end
end
The same problem of checking the value of several attributes can be
generalized. Something like this would be quite common in Ruby (and is,
in fact, the principle of many RSpec matchers that we cannot currently use).
def equivalent?(object1, object2, attributes = [])
attributes.each do |attr|
return false if object1.send(attr) != object2.send(attr)
end
true
end
That will crash very easily and most ruby developers wouldn't have
expected because disk.partition_table or partition.filesystem just look
like attributes.
The behavior of the methods when returning a value that is not set
should be uniform. If checking for a not-set integer or string typically
returns nil, checking for a not-set filesystem should do the same. It
must not be different and raise a very particular kind of exception just
for some returned types.
Cheers.
--
Ancor González Sosa
YaST Team at SUSE Linux GmbH
--
To unsubscribe, e-mail: [email protected]
To contact the owner, e-mail: [email protected]
