Feature Better exception handling in ASH

[Catch-22]

This probably happens with other ASH functions, but I noticed this specifically with substring(), so I'll use that as an example.

> ash substring("test", -1, 4)

Begin index -1 out of bounds ()
Returned: void

> ash substring("test", 4, -1)

Begin index 4 greater than end index -1 ()
Returned: void

Normally this is fine, but if you enclose the above code in a try/finally block, my expectation would be that the code is tried, the exception is thrown and the finally block is then ran. What seems to happen is that KoLmafia stops script execution as soon as the exception is thrown.

I haven't looked at the code, so I don't know if it's simply because try/finally only works with abort/return/break/continue and not actual exceptions. If that's the case, I would suggest that we handle known exceptions within ASH by entering an abort state and printing an error message instead of throwing an exception. This would behave well in normal situations but execute the finally block in a try.

 

[Catch-22]

Any thoughts on this?

I came across it again today whilst trying the following code snippet:

boolean function_exists = false;

try {
	functionInExistentialCrisis();
	function_exists = true;
}
finally {
	if (function_exists) {
		print("I am defined, therefore I am.");
	} else {
		print("I vanished in a puff of logic.");
	}
}

Function 'functionInExistentialCrisis( )' undefined. This script may require a more recent version of KoLmafia and/or its supporting scripts.

I would expect the try block to break at line 4, and continue on line 7. Only the former appears to be the case.

 

[roippi]

I wouldn't expect a try/finally block to catch a compile-time error.

 

[Catch-22]

I wouldn't expect a try/finally block to catch a compile-time error.

I presume you are talking about the 2nd example, which throws an exception in the parser instead of the interpreter. There's also an undefinedFunctionException in the interpreter, so in that case the interpreter would throw the exception if the contents of the try block were simply ignored by the parser, but it could be handled in other ways too.

What are your thoughts on exceptions thrown by the interpreter, such as the case with my first example?

 

[roippi]

Yes, I was referring to your second example.

It would be good if runtime exceptions (i.e. your original example) were handled by try/finally, certainly. Rather nontrivial to code of course - right now they just unwind the whole stack.

 

[Catch-22]

It would be good if runtime exceptions (i.e. your original example) were handled by try/finally, certainly. Rather nontrivial to code of course - right now they just unwind the whole stack.

"Nothing in KoLmafia is worth coding unless it's nontrivial" -- Theodore Roosevelt

Perhaps I'll look into it then, just making sure it's not just me who thinks this would be something nice to have.

 

[heeheehee]

There's also an undefinedFunctionException in the interpreter

Probably for call.

 

[Catch-22]

Probably for call.

Well, I assume it is just a relic from before the days of script validation, but I only looked briefly.

Theoretically, it would still be possible to throw that exception by modifying what goes on the interpreter stack. It's definitely something that should stay there, even if the exception wouldn't be thrown under normal circumstances.

 

[heeheehee]

Clarification: call.