On 24.11.2015 15:15, Josef Reidinger wrote:
Well, in OOP is also one more approach called NullObject pattern, which is create kind if partition table, that in represent no partition table.
This is wrong on so many levels that I don't even know where to begin... This proposed NullObject pretends to do a lot of things that it can't deliver. It makes false promises. And I can't even tell that it does that - to the outside world, it looks just like the real thing; the difference being that it does not do anything useful, so there is no reasonable way to handle the other case.
so if NoPartitionTable is used and its partitions return single partition, that is in fact filesystem on disk.
Only that I really need to know the difference in most cases because I have to do different things. To stay with the current example: A disk might have - an old-style MS-DOS type partition table with 4 slots (where I need to use an extended partition if I need any more partitions) - a new style GPT partition table that can have any number of parititions - a filesystem directly on the disk device without any partition table It sounds tempting to hide those gory details in the lib. But then, we do need to know a lot about this because we might have to do different things in the storage or bootloader proposal. It might just change the requirements if or when we need any of the boot partitions (/boot, EFI-boot, PReP) etc. etc. So, since we are doing deeply technical stuff here, I fear we need to know and to handle the gory details. Too much information hiding will become counterproductive here pretty quickly. There be dragons. ;-)
JFYI new ruby 2.3 will have &. operator for such cases, so you can then write it like:
if disk&.partition_table&.gpt?
Yikes, that's really ugly. When Moses came down mount Sinai, he must have dropped some stone slabs - that one, for example: Thou shalt not use crazy interpunction in the middle of source code. ;-)
which looks a bit better
I strongly disagree on that point.
OTOH if there would be more checks that might fail (such as the 'if disk && disk.partition_table && disk.partition_table.gpt?' check above), that one 'begin..rescue' block would handle them all, and the control flow remains clear and straightforward.
And that's the beauty of it.
Well, I am not sure as you should use more specialized exception catcher, otherwise you can catch also other problem, that should go more top level, so in the end, you might want to rescue from three kinds of exception like
rescue NoPartitionTable, NoDisk, NotGpt => e
Those things tend to accumulate - the exception types as well as the ones caught in the rescue clauses.
Using exceptions and not checks all over the place can help to clarify the algorithm without clobbering the code with that checking code - code that is very rarely executed and thus mostly untested (try to create test cases for all those if/else branches!).
on other hand testing all potential raiser of exception is also quite tricky.
There are much less cases to test.
Kind regards
--
Stefan Hundhammer