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

[Ralph Versteegen]

On 11 January 2018 at 18:46, Ralph Versteegen <teeemcee at gmail.com> wrote:

>
>
> 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).
>

To clarify, this would be in addition to a method of catching errors, but
the error catching can be an undocumented feature for our own purposes.

>
>
>> 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/16549d52/attachment.html>