Inconsistent data causes exception in IndexItem that halts processing

[patrickdalla]

When implementing #43, some values that come from external parsers are inconsistent with expected data type, more specifically in field ExtraProperties.LOCATIONS.

It is possible to treat this locally in the Task, but, as values come from "uncontrolled" external source (ALeapp), some unpredictable value can still occur.

This value (an address instead of a double coordinate) causes ALL the processing halt with the exception thrown at line 562 of IndexItem class at IndexTask.

Maybe it is a designed wanted behaviour, so, not necessarily a bug of IndexTask, but of the Task/Parser that puts wrong data type values.

But for similar cases, the end user would have nothing to do but wait for a Task/Parser bug correction to process the case. Maybe we could, alternatively, put the wrong value in an alternate property, named with the same property name, but with some prefix or suffix indicating the inconsistency. So the process can continue, and the data itself would be not lost, and the "errors" could be checked by the end user or even warned if desired in the LOG statistics.

[lfcnassif]

not necessarily a bug of IndexTask, but of the Task/Parser that puts wrong data type values.

This is the case, ExtraProperties.LOCATIONS was designed to store just GPS coordinates.

I think the parser should know better the data it is decoding, so it could better handle the data.

Generally, my concern about catching exceptions and continuing instead of aborting is to stop being warned by users and miss the chance to fix/handle the data properly, since today we do not collect processing logs for later improvement...

[patrickdalla]

Right, as ALeapp will have its own metadata prefix scope, it won't mix with other metadata, with the exception of ExtraProperties.LOCATIONS, in which case, I will treat any unexpected value.