Bug #750

Assertion in XmpParser::encode should be an exception

Added by Andreas Huggel about 6 years ago. Updated almost 5 years ago.

Status:ClosedStart date:02 Jan 2011
Priority:NormalDue date:
Assignee:Andreas Huggel% Done:

100%

Category:xmp
Target version:0.21.1

Description

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"

Associated revisions

Revision 2425
Added by Andreas Huggel about 6 years ago

#750: Replaced assert with exception.

Revision 2439
Added by Andreas Huggel about 6 years ago

[0.21.1] Merged fix for #750 from the trunk (c2425).

History

#1 Updated by Andreas Huggel about 6 years ago

  • Status changed from Assigned to Closed
  • % Done changed from 0 to 100

#2 Updated by Andreas Huggel about 6 years ago

  • Status changed from Closed to Resolved

#3 Updated by Andreas Huggel about 6 years ago

  • Target version changed from 0.22 to 0.21.1

#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.

Andreas

#6 Updated by Andreas Huggel almost 5 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF

Redmine Appliance - Powered by TurnKey Linux