[Ohrrpgce] assert that a particular piece of code has a script error?

Ralph Versteegen teeemcee at gmail.com
Wed Jan 10 21:46:59 PST 2018


On 10 January 2018 at 05:32, James Paige <Bob at hamsterrepublic.com> wrote:

>
>
> On Tue, Jan 9, 2018 at 8:17 AM, Ralph Versteegen <teeemcee at gmail.com>
> wrote:
>
>>
>>
>> On 10 January 2018 at 05:12, Ralph Versteegen <teeemcee at gmail.com> wrote:
>>
>>> There's no such feature. Its absence is certainly a nuisance for writing
>>> test cases.
>>> (hspeaktest.py can check for compile-time warnings and errors, but not
>>> run-time ones)
>>>
>>> I didn't have any ideas for a try/except block statement. I thought that
>>> people wouldn't use it much since most wouldn't be familiar with
>>> exceptions, and the additional complexity, didn't seem to justify it.
>>> But maybe a more coarse-grained ability to specify a global (or
>>> per-script or per-fibre) error handler would be useful. Either just for our
>>> purposes, or as a public feature.
>>> Incidentally, lua doesn't have try/except, but it has a special way to
>>> call a function so that you catch errors inside it (pcall).
>>>
>>
>> Also, when it comes to the differences between release and debug modes, I
>> suppose that you could use error catching either to catch errors that will
>> actually be shown to the user (so you can customise that), or to catch
>> errors (oh a certain errorlevel?) regardless of whether they're shown,
>> which useful for testcases... but what use would there be? Because we want
>> to be able to assume everyone uses release mode, and add new error
>> checking, I think any other uses of error checking would make adding more
>> error checking a back-compat problem again :/
>>
>>
>
> I think something like lua's pcall would be great. I just thought of
> try/except since that Is what I am most familiar with.
>

The pcall approach does seem like the appropriate amount of simplicity.

But pcall is intended to catch fatal errors that were raised either with an
error() call or when you do something illegal like try to dereference
something that's not a table. That's different from HamsterSpeak, where
errors are never fatal unless they're really bad, like corrupt script data,
or if the user chooses to stop the script.
But if pcall only catches things that would have caused visible error
messages, that could make sense since those could have resulted in the
script being stopped.

But making release/debug mode change the behaviour of pcall means it is not
at all useful as a replacement for try/catch - the flow control would
change completely! Then it's really nothing but 1) a way for us to write
testcases 2) a way to customise the script error display. In case 2) I
don't see any point in letting you restrict the guarding to a specific
script call.  If we want real exception handling functionality, perhaps we
should instead add "non-local" returns which aren't related to errors at
all: a throw() function and a callandcatch() function (which is the same as
pcall but it only catches throw() non-local exits, since errors normally
never cause non-local exits).


> Just checking user-visible errors seems good enough for writing better
> test cases, since it should be very little trouble making sure that
> autotest.rpg gets run in debug mode (it looks like we don't currently have
> a command line argument to force testing mode, but it ought to be easy to
> add one)
>

Hmm, we have the --errlvl cmdline arg, but it appears to do nothing in
release mode, since scripterr requires both gen(genCurrentDebugMode) <> 0
and errorlevel > err_suppress_lvl before showing an error.

---
James

>
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20180111/3412818d/attachment.html>


More information about the Ohrrpgce mailing list