[OSM-dev] Osmosis Output Error

[Brett Henderson]

Karl Newman wrote:
> The SRTM data has no timestamps, which is causing the problem. So you 
> only need to set enableDateParsing=false for that file. It might be 
> good to show a warning if an entity has no timestamp attribute in the 
> XML. I propose adding the following lines in BaseElementProcessor.java:
>
> +    private static final Logger log = 
> Logger.getLogger(BaseElementProcessor.class.getName());
>
> ...
>
>     protected TimestampContainer createTimestampContainer(String data) {
>         if (enableDateParsing) {
> +            if (data == null || data == "") {
> +                log.warning("Element missing timestamp attribute.");
> +            }
>             return new UnparsedTimestampContainer(timestampFormat, data);
>         } else {
>             return dummyTimestampContainer;
>         }
>     }
Cool, I agree that this is the place to do it.  It avoids subsequently 
fail 3 tasks down the pipeline because input data was dodgy.

I'd rather not just log a warning though because nobody reads them and 
it's going to fail anyway.  I'd prefer to just make it abort at that 
point.  I'm hoping the xml reading code will provide a line number or 
something when the SAX parser receives the exception but that'll have to 
be tested.  The other option is to throw a sub-class of 
OsmosisRuntimeException (which I should just rename to OsmosisException 
incidentally) which can then be caught further up the stack and the 
relevant contextual information added in and re-thrown with the original 
exception as the cause.

The exception could even include a short message suggesting that 
enableDateParsing=true might be necessary.

The Entity class could probably be tightened up as well to catch dodgy 
data if the input tasks don't do it.  It would at least make an error 
occur near the source of the problem.
>
> That encapsulates it in the lowest possible level, but the downside is 
> that it doesn't report anything about the problematic element--Ideally 
> it would show the id and whether it's a node, way or relation. That 
> could conceivably be solved by passing that information to the 
> createTimestampContainer method, but that seems sloppy.
I often seem to run into this problem.  The best solution I can think of 
is the above approach of exception chaining adding context as you roll 
back out of the call stack.  I'd rather not do it too often though, 
error handling starts to add more code than the app logic itself, 
perhaps best to just add information to help common problems as people 
encounter them.

Brett