Re: format error? Boy is that confusing!

On 5/6/2015 3:53 AM, Robin Becker wrote:
> On 05/05/2015 22:44, Glenn Linderman wrote:
> .......blem.
>>
>> What makes this stack trace so unintelligible, is that it says 
>> "format not
>> resolved" and then shows a relative URL.  It makes it seem like it is 
>> trying to
>> interpret the URL as a format code (of some unknown sort), and my 
>> thoughts
>> immediately went to the possibility of having omitted the format code 
>> parameter,
>> and supplied the URL as the wrong parameter, somewhere along the 
>> line, and of
>> course doc.build has so many deferred operations that there is little 
>> clue as to
>> where in the document this actually takes place.
>>
> here format appears to refer to a .fmt attribute in the Destination 
> object. Destinations are created when a reference is made to them, but 
> need to be filled in by a later definition so that a click on the tag 
> / link or whatever can jump to the appropriate place. Like <a> in html 
> they are both a link and a target. I assume that the document never 
> saw '../../hc/foo.png' as a target and so the definition of the 
> destination never got carried out.

I don't fully understand the above, but the message did contain the text 
'../../hc/foo.png', so something saw it, and got it into the message.  
The flowable text was '<a href="../../hc/foo.png">'.  So it seems like 
href would be a big clue as to what was supposed to happen?  But I 
realize that at that depth of call stack not everything would 
necessarily be in context.


>
>
>
>> It would be extremely more useful to for the message to say something 
>> like "URL
>> scheme missing" or "unknown scheme" using the terminology for URLs.  
>> If, at the
>> point of error generation, it truly is not known, and cannot easily 
>> be known,
>> whether this is a "format" (whatever that means) or a URL (which is 
>> missing its
>> scheme), then having the message say "format unresolved or URL scheme 
>> missing"
>> would certain be an improvement in clarity at little expense of 
>> reworking the
>> code (just changing a message).
>>
> Since the destination definition never got seen we don't actually know 
> what was intended. I suppose a better error message might be "target 
> of destination with name '../../hc/foo.png' was not defined", however, 
> that doesn't cover the semantics of the case where you just forgot to 
> put in http and the link was to an external. So perhaps we can use
>
> "missing URL scheme or undefined destination target for xxx"

I'd have understood this one, so it would be an improvement from my 
perspective.  When I saw format, I immediately thought of  "printf" type 
formats, or that sort of thing, a format code that controls text 
arrangement. And maybe that is what is happening at the lowest level of 
the stack, but the '../../hc/foo.png' is certainly not supposed to be 
the format.... it is what is supposed to be formatted.

Thanks!


>
>
>> Personally, I have no clue what other cases would cause the message, 
>> that would
>> make "format not resolved" a useful message, but I'm making the 
>> assumption that
>> such a case exists.
>>
>> Here's an abbreviated stack trace:
> ........
>>      if f is None: raise ValueError("format not resolved %s" % 
>> self.name)
>> ValueError: format not resolved ../../hc/foo.png
>>   Errorlevel 1 from bixutls.py.  Exiting.
>>
> /........