Closed GoogleCodeExporter closed 9 years ago
I dont see the advantage to return null. It still needs to be tested, so I
would prefer to keep the exception for something that is not defined.
Original comment by andreas....@googlemail.com
on 26 Apr 2011 at 9:04
Hi Andreas,
Imagine this scenario: for a given tag the image has a string value of "FOO".
However you are expecting the type to be of int, so you call getInt. There is
no sensible conversion from "FOO" to an int, so it throws an exception.
There is no way you could have known that this call would fail ahead of time
without reproducing the entire contents of the getter (it converts from many
scenarios.)
It's uglier and more likely to be mislead, in my opinion, to catch an exception
than to test for null. Everything that could be known before can still be
known now without having to catch exceptions to signal the presence of a
certain type of value.
I have created new methods "getInteger", "getFloatObject", and
"getDoubleObject" that return nullable numbers for times when you need them. So
if directory.containsTag(tagType) and directory.getInteger(tagType)==null, then
the value is there but can't be converted to an integer.
Note that arrays, strings, rationals and dates are all reference types so don't
need any special treatment.
Descriptor.get*Description methods no longer raise MetadataException. They are
all capable of returning null, just like they were before.
I've also annotated the entire API with @NotNull and @Nullable, so if your IDE
understands these tags (IntelliJ IDEA does) then you can avoid runtime NPEs.
Sorry but I did all of this before I saw your message and I must have missed
the email notification amongst all the other notifications, otherwise I would
have discussed this with you. I'm pretty happy with the change though.
Take a look and let me know what you think.
Drew.
Original comment by drewnoakes
on 27 Apr 2011 at 7:31
Original issue reported on code.google.com by
drewnoakes
on 26 Apr 2011 at 5:28