Best procedure for distinguishing between error and warning

[Cactus26]

I recently realized that I do not yet have a satisfactory procedure in my application for distinguishing between errors and warnings. The triggering example was the following:

Command:

Code Select Expand

D:\Fotos\2015\StefanL\2015-04-26 13.13.01.jpg
-1IFD1:7ID-Exif-ThumbnailImage:ThumbnailImage=
-overwrite_original
-execute4
StdOut:

Code Select Expand

    0 image files updated
    1 files weren't updated due to errors
StdErr:

Code Select Expand

Warning: [minor] Entries in IFD0 were out of sequence. Fixed. - D:/Fotos/2015/StefanL/2015-04-26 13.13.01.jpg
Error: Bad format (52562) for IFD0 entry 11 - D:/Fotos/2015/StefanL/2015-04-26 13.13.01.jpg
First: What do I mean by Error/Warning

I would define an error as when at least one action could not be executed, i.e. there was no fallback that could be used to fix the situation after all. This should essentially coincide with the philosophy of the ExifTool messages, as well as in this example. Warnings are logged but are not normally reported to the user. Errors must be reported to the user.

My guess is that parsing the text in StdOut might be the most sensible procedure. Can I rely on this format for write calls:

Code Select Expand

    x image files updated
    y files weren't updated due to errors

Also: Does my procedure for Read calls (s.a.) make sense?

I would be very happy to receive suggestions.
Cactus

[Phil Harvey]

Errors prevent the file from being written.  Warnings don't.  But I thought that should be obvious from the summary message, so perhaps I'm not understanding what you are asking.

- Phil

[Cactus26]

My primary concern is: Can I rely on this pattern for write calls or are there exceptions?

Code Select Expand

   x image files updated
   y files weren't updated due to errors
Jürgen

[Phil Harvey]

You can rely on that pattern.

- Phil

[StarGeek]

Just in case you haven't seen it, there is the -efile option to save the filenames of files causing errors.

[Cactus26]

Thanks a lot, guys! I hadn't noticed the efile option yet. Currently I only offer the option for updating one file, if I will enable more, this will be very helpful.
Cactus

[Cactus26]

I found an exception:

Code Select Expand

    0 image files updated
    1 image files unchanged
Are there more?
Cactus

[Phil Harvey]

Exactly what do you mean by "pattern"?

The text of each summary line always follows the same pattern.

There are a number of different summary lines which may appear.  Perhaps the C++ interface GetSummary() documentation is the best place to go for a list of these.

- Phil

[Cactus26]

Many thanks, this helps a lot. Excuse my misleading English.
Btw: I use my own C++ interface because I didn't want to complicate the installation procedure with cygwin.

If I have seen correctly, "Unchanged" also indicates errors.  I was worried that setting a tag to the same value would also be considered unchanged, but this does not seem to be the case, this case is reported as "Updated". Can I rely on this?
Cactus

[Phil Harvey]

Hi Cactus,

The only tag that reports "Unchanged" if you write the same value is FileName.  All others don't compare with the existing value when writing.

- Phil

[Cactus26]

Thanks, Phil, writing FileName is not an issue.

But I'm still fighting with error handling. I suspect that the summary is missing if -b is specified. Examples

Code Select Expand

exiftool file.JPG -artist=xxx -b
exiftool file.JPG "-ThumbnailImage<=thumbnail.jpg" -b
In this case there is no "1 image files updated". Is there a reason for this?
Cactus

Addendum1:
After I published this post, I checked the documentation again to see what the -b tag actually means when writing tags. I can't find any. I can't remember exactly why I decided to use it, possibly because I always use it when reading tags to file (saving the tag content to file) and I wanted to use it symmetrically.

Cactus

Addendum2:
I think I have found my reasons: If -b is used when reading a tag, the internal (num, suffix "#") value is implicitly used, if there is one. I had now assumed that the internal value is also used for -b when writing tags, even if the suffix "#" is not specified.

Cactus

[Phil Harvey]

Hi Cactus,

The -b option was never meant to be used when writing.

- Phil

[Cactus26]

Hi Phil,
that's fine, I add suffix "#" when writing to be symmetricial to my reading with "-b".
According to my tests, it doesn't matter if the suffix "#" is specified and there is actually no difference between internal and formatted format. If -b is nevertheless specified when writing, I would not mind an error message. The fact that it simply causes a missing summary is strange and initially led me on the wrong track, as I thought the missing summary was caused by reading the tag value from the file.
Cactus

[Phil Harvey]

For binary data tags, adding "#" makes no difference.  The only difference is when reading a file you get the actual data instead of the "(Binary data XXXXX bytes)" string.

There are many options combinations that don't make sense, and it would be a LOT of work to add warnings for all of them.

- Phil