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 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.