There are several things wrong with it, actually.
First, in my example, I never did actually return the longest error - I just set the location to the longest error location. �Not right at all.
Next, setting the stream to the position of the error on the choice is not a good idea. �The problem is when you have more than 1 choice depth. �So, the first choice goes down path 1, which calls another choice (eventually), which fails and resets the location to some point further on in the stream. �The the rollback to the first choice seems to get fouled up and doesn't work quite right. �Probably. �In any case, playing with how it is storing and returning, I am getting wildly different points of where the track fails.
Finally, the array at each choice doesn't necessarily pick the furthest failure. �If you consider a 4 choice depth parser (which is roughly what I'm working with - parsing Java source code), the 4th choice will fail on a couple of paths, and then eventually work on one. �This might then return back to the 3rd choice successfully (so no error, so no returned error from that choice) and then later fails. �That particular path might be much shorter (that it made it through) than the one that failed earlier (maybe a much more complex but also more consuming path, for example).
The question is what exactly are you (we) looking for. �
* I think we want to know what was the parsing path the best describes the source file we are parsing, and where is it failing to parse.
* I would also like to know what the path was that arrived at that point (the context) so that I can decide how to either fix the parser (if it is wrong) or fix the source.