What If It Can't Be Found

[paul_a_cardinale]

I'm trying to put together some code to read EXIF data.  But what should happen if it can't be found?

• Simply output a boolean indicating whether it is found or not.
• Inject a warning into the error flow.
• Inject an error into the error flow.

Certainly all are workable; but what is preferable?

[altenbach]

I guess it depends on what the downstream code needs to make decisions based on the state. Another option would be to just create a data structure that contains sentinel values for  information that is not available. (-1, Inf, etc.)

[paul_a_cardinale]

---

@altenbach wrote:

I guess it depends on what the downstream code needs to make decisions based on the state. Another option would be to just create a data structure that contains sentinel values for  information that is not available. (-1, Inf, etc.)

---

Although I'm making this for a specific app, I want it to be generic; so downstream code could be anything.

I'm wondering what would be most convenient generally.

[Kevin_Price]

I'd usually prefer the boolean indicator to a warning or error.  The calling code can always turn that boolean into a full-fledged "not found" error for apps that need such behavior.

I'd also like the "sentinel value" suggested by altenbach to be the default value for an optional input.  This kind of thing works nicely when you're already carrying a wire expressing "the value up until now, which should only be changed if the tag is found".

-Kevin P

[zou]

Enumerate all existing properties (data) to avoid reading non-existing data.

[BertMcMahan]

IMO, I'd mirror the functionality from existing, similar functions. Based on a couple minutes poking around:

Functions that have a "Found" output and do not add errors or warnings:

-Config file VI's

-The JSONText library (I know this isn't a standard toolkit but AFAIK it's reasonably widely used)

-Match Regular Expression does not have a Boolean output, but does have an "Offset past match" output that is -1 when the value was not matched, which can be converted to a boolean easily

-Get Variant Attribute

-Look in Map

Functions that don't have a "Found" output, and adds an error:

-Unflatten from JSON (LabVIEW's built-in JSON library) doesn't have a "Found?" output, and throws error -375005: Type mismatch between JSON and LabVIEW

-Scan From String does not have a "Found?" output, and throws error 85.

I'd argue that, following the "principle of least astonishment", that trying to read EXIF data that wasn't there is akin to trying to read a config file that wasn't there, or a JSON element that wasn't there, or getting a value from a map that isn't there.

The other two examples I ran across don't match super well. I'd argue that the built-in JSON library throwing a type mismatch is due to the "all or nothing" way that that function handles JSON lookups. In that case, you're doing a type conversion, rather than looking inside another "thing" for some values. Throwing an error does make sense, but then again I don't see a lot of people who really love the built in JSON functions. Scan from String is kinda similar to your use case of "find some subset of data in a bigger pool of data" so that's a point for that camp.

I like Kevin's idea to leave it as a Boolean and let callers decide what to do from there. For a lot of cases, e.g., displaying EXIF data in a preview pane next to a list of files, "not having EXIF data" isn't really an "error"- there just isn't any data there. If you had a function like "Process this image using a specific transform correlating to the lens identified in the EXIF data", then an error would make sense- you simply can't do what you wanted to do, since the data wasn't there. That "feels" more like an error to me, but that would happen at the "get transform" function level, not the "Read EXIF data" level.

Just my 2 cents.

[paul_a_cardinale]

---

@zou wrote:
Enumerate all existing properties (data) to avoid reading non-existing data.

---

That's not possible since not all image files have all possible EXIF tags.

For instance, a file may or may not have GPS data.

[zou]

"Enumerate" might be a little bit misleading.

What you could do is get count (number of properties), then iterate though each of them, by indexing, not by name.

There are only hand full of data types, such as: string, numeric, rational, etc.

So a driver should looks like "Configuration File VIs", by data type, not by tag name,

[BertMcMahan]

---

@paul_a_cardinale wrote:

---

@zou wrote:
Enumerate all existing properties (data) to avoid reading non-existing data.

---

That's not possible since not all image files have all possible EXIF tags.

For instance, a file may or may not have GPS data.

---

Another issue regarding whether or not to inject an error. Following standard error functionality, if you call a bunch of functions in a row to try for a bunch of different EXIF tags, I'd assume you would want subsequent ones to keep functioning even if an upstream one didn't find what it was looking for.

I'd assume you WOULD want to throw an actual error if, say, the data was corrupted and you couldn't read from it at all- like if a file was closed. In that case, I would assume you'd like standard error functionality, so subsequent attempts would just skip and you can get straight to your error handling code.

If you are injecting errors on each "Tag not found", and you want it to keep iterating if a tag isn't found, you'll have to filter out the Not Found error and report it separately from "File corrupted" or similar errors (which you DO want passed up the chain). At that point you've just duplicated the "no errors on the line but have a boolean if not found" functionality.