Exception Handling

I’ve been making a lot of small bug fixes as I’ve worked through calculating the data for a simple concordance. My current test is with 522 transcriptions (around 20-25 lines each) resulting in a word list with 7677 entries showing how often the word appears and on which pages. It takes about 2.5 minutes to run. I’m focusing on correctness right now. I’ll worry about optimization later.

One of the problems I ran into was the document parser throwing an occasional error. The engine can’t handle that right now, and the result is not always pretty or helpful. With that in mind, I’m adding some structural components that should help.

Any context within which you can have a list of actions will automatically create an exception handling scope. Within that scope, you can use the ensure element to specify code that should get run even if there is an error (it will run before the exception is handled and any exceptions raised will not be caught by the sibling catch elements). The catch elements can have a @test associated with them that, if true, will cause the enclosed actions to be run. All catch elements which have a true @test will be run. The result of the last catch will be the returned result to the parent action. If no @test is available, then it will be assumed true. Not sure yet how it will access the exception, but probable through a variable.

There should be an identity action that returns the result of the last contained action. This would make it easier to scope exception handling. I’m not sure what to call that element yet, but it will be there eventually. Candidates include ‘nop’, ‘div’, ‘scope’, ‘identity’.

Published by

James

James is a software developer and self-published author. He received his B.S. in Math and Physics and his M.A. in English from Texas A&M University. After spending almost two decades in academia, he now works in the Washington, DC, start up world.