<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 10 January 2018 at 05:32, James Paige <span dir="ltr"><<a href="mailto:Bob@hamsterrepublic.com" target="_blank">Bob@hamsterrepublic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><span><br><div class="gmail_quote">On Tue, Jan 9, 2018 at 8:17 AM, Ralph Versteegen <span dir="ltr"><<a href="mailto:teeemcee@gmail.com" target="_blank">teeemcee@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On 10 January 2018 at 05:12, Ralph Versteegen <span dir="ltr"><<a href="mailto:teeemcee@gmail.com" target="_blank">teeemcee@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div>There's no such feature. Its absence is certainly a nuisance for writing test cases.<br></div>(hspeaktest.py can check for compile-time warnings and errors, but not run-time ones)<br><br></div>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.<br></div>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.</div><div>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).<br></div></div></blockquote><div><br></div></span><div>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 :/<br></div><span><div> </div></span></div></div></div></blockquote></div><div class="gmail_quote"><br></div></span><div class="gmail_quote">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.</div></div></div></blockquote><div><br></div><div>The pcall approach does seem like the appropriate amount of simplicity.<br></div><br></div><div class="gmail_quote">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.</div><div class="gmail_quote">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.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">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).<br></div><div class="gmail_quote"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><br></div><div class="gmail_quote">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)<br></div></div></div></blockquote><div><br></div><div dir="ltr">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.<br></div><div dir="ltr"><br><div class="gmail_extra">---</div><div class="gmail_extra">James<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>______________________________<wbr>_________________<br>
Ohrrpgce mailing list<br>
<a href="mailto:ohrrpgce@lists.motherhamster.org" target="_blank">ohrrpgce@lists.motherhamster.o<wbr>rg</a><br>
<a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" rel="noreferrer" target="_blank">http://lists.motherhamster.org<wbr>/listinfo.cgi/ohrrpgce-motherh<wbr>amster.org</a><br>
<br></blockquote></div><br></div></div>