Custom Error Handling Prototype

[ianjosephwilson]

• Reworked the SourceTracker
  • I think our original thinking was that the current HTMLParser.getpos() could be reconciled with the current string/interpolation index of the Template while feeding parts but there does not seem to be an easy way to do that.
• Added ParserPositionTranslator, LineLocation and PartLocation
  • Instead we take the target parser position, parser_pos: LineLocation and a current position pos: MutableLineLocation, and walk pos through the Template parts with the embedded placeholders looping via index and offset until parser_pos == pos and source_pos = PartLocation(index, offset).
• Added SourceInfo (and OpenSourceInfo), TTree and source_pos for TNode subclasses
  • We store the source_pos on each tnode after we translate it from the parser_pos.
  • In addition to the source_pos we can also store if a tag was self closing (or startend), the full starttag_text as starttag_ref and the endtag_pos (if startend==False). This info is in SourceInfo (for accessing via completed nodes) and OpenSourceInfo for incomplete nodes
  • When we create the completed SourceInfo we store it separately from the nodes and pack it into the TTree so we can unpack when an exception occurs. The reasoning for this was to try to keep most of the error/source details separate from the core processing to keep the core flows clear from debugging/error info churn and also in case that information is not available.
• Added SourceReader
  • Now that we have translated source positions we have to "read" the source on errors so we have a utility class that is spawned by the SourceTracker with the appropriate template to extract the source with the interpolation expressions (when already raising errors) as well as translate PartLocation to LineLocation (but dependent on the string representations of the interpolations).
• Added ParsingError(s)
  • Involves one template (that might contain inlined component children)
  • Should not involve the actual values of the template (unless we use them AFTER an error already occurred)
• Added ProcessingError(s)
  • Recursive: Can occur in a template that was included in another template which was included in another template ... etc.
  • Once an exception occurs try to pack up a state that parallels each template in the recursive stack
    • Try to connect each "leaf" entrypoint with the nearest TNode
    • Try to connect the template and TTree (contains the template TNode root) to the exception
    • Try to catch regular exception in places where they might occur, ie. we try to call a user function, and then chain them with raise ProcessingError() from e
    • We also catch and chain a ParsingError to a ProcessingError
  • When we get back to TemplateProcessor.process() we should have a single ProcessingError that has a stack of error states that go down until we reach the lowest level Template where an error first occurred so we could print something LIKE this (TBD):

div > ... {nested_t}
    div > ... {slider_t}
        span > AttributeProcessingError: aria attribute must be dictionary
Error occurred in <span aria={('role','slider')}></span> at line 1 offset 15 in 

• Improve various error messages
  • Mismatched tags, unclosed tags, etc. should have better error messages.
  • Special messages for some hard to catch errors around the now notorious trailing slash (self closing or not self closing).
  • Try to show the relevant tag when applicable.
• TODO:
  • Come back and try to plug all the "holes" where an exception might be expected and need to be wrapped in a ProcessingError or ParsingError.
  • The tests I think need a bit of refactoring.
  • Test that component invocation errors are propagating correctly.
  • More thorough unrolling of processing errors when coming out of nested templates.
  • Utilize values_index and iter_index when displaying an error.
  • I have the "raw_attrs" stored in the SourceInfo right now but we might want to try to just get by with the tattrs on TComponent/TElement/OpenTComponent/OpenTElement themselves and remove this.

[davepeck]

@ianjosephwilson Just saw you flipped this out of draft. Will take some time to work through it, but... wow!

[ianjosephwilson]

@davepeck Yeah I think we want to start wading through it before I add even more LOC... I ended up having to follow the concept all the way through the processor to determine how things played out to then backtrack that to the parser to get a working design.. working. It is a lot of parts but I find it easier to see all the parts fitting together (or not fitting).