Mailinglist Archive: yast-devel (127 mails)

< Previous Next >
Re: [yast-devel] New libstorage: Returning NULL pointers vs. throwing exceptions
  • From: Stefan Hundhammer <shundhammer@xxxxxxx>
  • Date: Tue, 24 Nov 2015 15:47:24 +0100
  • Message-id: <5654787C.1070308@suse.de>
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 <shundhammer@xxxxxxx>
YaST Developer

SUSE Linux GmbH
GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg)
Maxfeldstr. 5, 90409 Nürnberg, Germany
--
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups