It was a poor piece of naming when errors were called exceptions. Errors are to be expected as normal and only to the mind of a novice are they exceptional. Consider the business of loading in some data from a file. What can go wrong?

First the file may not exist. And if it does exist, it may be locked against reading. If not, it may be empty. If not empty the data may not be formatted in the way the program expects.

In general we see that a procedure's success may depend upon navigating through a thicket of obstacles, and that each failure may require different information to be passed back to the user.

Many of the functions in Lua's built-in libraries use a particular convention for signalling success or failure. This convention is possible because in Lua functions can return more than one value at a time. The convention is that success is signalled by the first returned value being neither nil nor false, and that in the case of failure a second value is returned as an error object . An error object may be a string, an error-message, maybe a key in a table of error-messages, or perhaps a function to be called. See sections 16.3 to 16.5 in the fourth edition of Programming in Lua.

Section 5 of the PRMs (page 1-41) explain that SWIs come in two forms, error-generating and error-returning (the X form). The function riscos.swi always translates its first argument, an SWI number or string, to the X form, and it adopts the convention mentioned above. Lua knows nothing of SWIs. An SWI called with silly arguments can cause mayhem, and may not return at all. But otherwise, if the first value returned is nil or false, the second will be an error-message.

Wimp programs share their control of the computer with the task-manager. They register themselves as wimp-tasks by calling Wimp_Initialise, and yield control to the task-manager by calling Wimp_Poll or Wimp_PollIdle. These calls return with an event-code and with event-data in a buffer. The task then responds to these accordingly. It makes sense for these responses to be values in a handler-table, indexed by event-codes. These handlers will be functions and they should indicate by their returned values not only success and failure but also whether the task is to continue or not; if yes to go back to the polling loop, and, if not, to clean up and call Wimp_CloseDown. There are quite a few possible schemes to adopt.