BASIC error handling

Can we pretty please have improved local error handling, along the lines discussed in this thread?

A simple case would be rethrowing after tidying up in a procedure,

DEF PROCdo_file(f$)
  LOCAL H%
  LOCAL ERROR
  H% = OPENIN f$
  IF H% = 0 ERROR 0, "Coudln't open file"
  ON ERROR LOCAL RESTORE ERROR : IF H% <> 0 CLOSE#H% : ... rethrow error somehow ...
  ... process file ...
  CLOSE#H%
ENDPROC

Uhhh…?

Don’t you want an FN instead of a PROC there?

In that way, it can return zero if the operation worked, and anything non-zero is some sort of error code. Therefore, ERROR needs only be local use for trapping BASIC statements that may raise errors. Otherwise, the function passes back values to say what happened, or if you only care whether or not it worked, a simple TRUE/FALSE.

So:

[...blah...]
IF ( FNdo_file("$.thingummajig" <> FALSE ) THEN
  [...oh crap...]
ENDIF
[...]


DEFFNdo_file(f$)
  LOCAL H%
  LOCAL ERROR
  H% = OPENIN f$
  IF (H% = 0) THEN : =1
  ON ERROR LOCAL RESTORE ERROR : IF H% <> 0 CLOSE#H% : =2
  [... process file ...]
  CLOSE#H%
=FALSE

In my actual code it is a function, trapping BASIC statements is the issue, specifically passing both ERL and REPORT$ up to the error handler of the caller.

specifically passing both ERL and REPORT$ up to the error handler of the caller.

It doesn’t have to be raised as an error does it?

Could the function not return zero or construct an error block?

Think of how C does it – because there’s pretty much no centralised error handling in C except for the things that signal() provides, and if you hit one of those, the best thing you can usually do is tidy up as best you can and then abort.
Thus, in C, everything that could cause an error is checked (yes, it’s tedious, and probably why C++ introduced the try/catch paradigm) and as such functions tend to return some sort of “it worked / it failed” status. Which may be a simple TRUE/FALSE, or could be a NULL/pointer to error block. The callee then looks to see what was returned, and deals with it as appropriate.

[I know you know this, just explaining it here for people who are unfamiliar with C]

Don’t think that you can propagate ERL.

I usually have

DEF PROCraise
IF NOT raised% THEN raised%=TRUE: ERROR ERR,REPORT$+" at line "+STR$ERL+" in ThisProg"
ERROR ERR,REPORT$
ENDPROC

...

DEF FNdo_stuff
LOCAL H%
LOCAL ERROR: ON ERROR LOCAL: RESTORE ERROR: CLOSE#H%: PROCraise
...
RESTORE ERROR
CLOSE#H%
ENDPROC

Can you not simply use something like:
ON ERROR LOCAL RESTORE ERROR: ERROR ERR,REPORT$+" at line "+STR$ERL
to ‘throw’ the error to the previous error handler?

My great annoyance with BASIC error handling is that the stack is deleted before the handler takes effect. This means that *reportstack in an error handler doesn’t give you any information about the route to the error.

This usually means I have to add *reportstack to the lowest function/proc I can identify, to be called every time the function is entered, and then trigger the error again – if I can work out how to trigger it.

@Martin If you have more than one nested local handler you just get a string of appendages that may unhelpfully grow too long

I think if ERL is important to the caller’s hander you could use

DEF PROCraise
IF NOT g_erl% THEN g_erl%=ERL
ERROR ERR,REPORT$
ENDPROC

@Alan: Yes, that annoys me as well. The only solution I have is a variation on the above:

ON ERROR LOCAL RESTORE ERROR: OSCLI("ReportStack"): ERROR ERR,REPORT$+" at line "+STR$ERL

@Stuart: Yes – if you have several nested handlers using a variable like that would be better.

Can we pretty please have improved local error handling, along the lines discussed in this thread?

That was some thread, wasn’t it? ;-)

… rethrow error somehow …

What that needs is ERROR to jump directly to the current error handler without changing ERR, ERL or REPORT$. B***** (not Brexit) provides this, but from BASIC itself you have to do some magic. From that thread this was my suggestion:

DEFFN_ERROR
LOCAL k%
DIM k% LOCAL TRUE
k%!-8=!&8684 
=TRUE

which you call as IFFN_ERROR.

There was also a method for nested error handling using CASE, but that used magic as well.

Would you like your FN/PROC routines to report errors including where they are called from? A bit more magic can do that. It might even be easier than reporting the stack. ;-)

It might be worth posting the assembler for a CALL_ERROR routine:

DEFPROCCALL_ERROR
 DIM P% 11
 [OPT 2
 ._ERROR
 LDR r0,[r8,#-124];pointer to error handler
 STR r0,[r13,#16];return address from CALL
 MOV pc,lr
 ]
ENDPROC

IF H% = 0 ERROR 0, “Coudln’t open file”

Two problems with that.

Error 0 is a fatal error, defined to stop the interpreter and bomb out to the command prompt.

The error number for “couldn’t read a file” is 214. Not some random number made up by yourself, but 214. (192 for “couldn’t write to a file”.)

IN% =OPENIN :IF IN%=0 THEN ERROR 214,“Couldn’t open file”

OUT%=OPENOUT:IF OUT%=0 THEN ERROR 192,“Couldn’t save to file”

If you generate errors yourself you must must must MUST MUST use the correct error numbers, otherwise you are kicking in the nads anything that uses ERR – which includes other programs that call your program, not just yourself. You can’t just say “I don’t care what my error numbers are” – the outside world cares.