Assertion in XmpParser::encode should be an exception
|Status:||Closed||Start date:||02 Jan 2011|
|Assignee:||Andreas Huggel||% Done:|
A command to set an XMP value with an invalid type triggers an assertion in the XMP encoder:
$ exiv2 -M "add Xmp.iptcExt.CountryCode String US" file.jpg exiv2: xmp.cpp :638 : static int Exiv2::XmpParser::encode(std::string&, const Exiv2::XmpData&, uint16_t, uint32_t): L'assertion « val » a échoué.
The assertion should be replaced with an exception which explains the problem, e.g., Xmp.iptcExt.CountryCode has invalid XMP type "String"
#4 Updated by Dimitri Schoolwerth over 5 years ago
I had problems with the assert too and locally had replaced it with a 'continue' for the loop (not the best solution either since it silently ignores an error). The problem that I have with the throw is that I'm copying metadata from an existing image file to a new image that should have (mostly) the same metadata. This existing file already contains an XMP value with invalid type. With the throw it results in the XMP data not being there at all in the new image (unless I'm mistaken). Or is the idea behind this throw that I should catch the exception, fix the type somehow and then try again?
Additionally maybe Exiv2 should compensate for this invalid XMP type and fix the type itself? (I would have to dig up the image again, IIRC it came from a camera but I don't recall which one and how widespread it is)
#5 Updated by Andreas Huggel over 5 years ago
Exiv2 generally throws when it doesn't know what to do anymore. In some cases the application is in a better position to decide. The original issue here was that an Exiv2 IPTC type was used for an Exiv2 XMP property. That's a simple user problem. What you're describing sounds more like an invalid source XMP packet. I'd think that exiv2 should just say so and refuse to cooperate. Yes, a sample image and a use-case that demonstrates the issue would be helpful.