adMartem Regarding the try/catch/finally construct in JavaCC
I don't know whether you came across this blog article in which I made no bones about my skepticism regarding the usefulness of the try-catch construct in legacy JavaCC. I mean, given the fact that parsers generated by legacy JavaCC include basically zero disposition for backtracking or recovery...
Though, to be clear, you can still use this construct in CongoCC, I never removed it, but my doubts about its usefulness remain. Well, to be clear, I wouldn't say either that it is totally impossible to recover and get back on the rails somehow, at least in some cases maybe, but it would really be some kind of black art! And also, it is quite possible that you can do something or other that is better than nothing -- which is kind of what I'm guessing is your case in the above. So, I mean, I'm not saying that you can't do anything in a catch block, but let's face it. It's bound to be something quite crude! (Which again, may well be better than nothing, but...)
But that blog article, which I see was written 2 years ago (how time flies!) I mentioned that I had implemented an alternative to try-catch, which is ATTEMPT/RECOVER. The code is still there for that, but it is basically untested. You see, normally, when I implement a new feature, I try to use it internally pretty quickly. So, the up-to-here stuff I was talking about, for example, that's used so extensively internally that, by now, it is as solid as any other core feature really. But that is not the case with the various fault-tolerant/error-recovery sort of stuff. I was gratified that 'ngx' seemed to be putting the fault-tolerant stuff to good use, but I do need to make 100% clear that this sort of stuff is nowhere near as tested as other things.
With the ATTEMPT/RECOVER I describe in that blog post from 2 years ago, I implemented it and I must have done a bit of checking to see that it seemed to work, but I never got any feedback from anybody about it one way or the other and it's not being used internally, so I can't even affirm that it still works! Possibly, due to code drift, it doesn't even work! It seems that the fault-tolerant stuff described here does basically work, though I mostly know that from the recent posts by ngx.
Well, I think the approach described is basically valid and it does work (mostly) but I have to make clear that if you use it, you should be doing so on the understanding that it's not as solid/tested as other things and really, you should be trying to help me get the kinks out, reporting any problems you run into.
But all that said, fault-tolerant is where it's at. So I anticipate that, once we get the CongoCC renaming fully done, probably fault-tolerant will be on by default. Unless you explicitly turn it off. (And besides, how do you get anything tested anyway, as a practical matter... people out there do have to start using it!)
Now, as for the ATTEMPT/RECOVER, the idea there is well motivated, I think. Well, the basic difference is that with ATTEMPT/RECOVER, the parser machinery (if you hit an error in the ATTEMPT block) rewinds to the state it was in just before the ATTEMPT block. So I thought this would be more generally useful! But, again, I'm not even 100% sure that ATTEMPT/RECOVER still works! But if it doesn't and you have a clear use-case, we'll beat it into shape.
So that's about where things stand...