error handling / signalling

[gnarz]

generally error handling seems to be a big todo in libui. Basically there is hardly any... lots of libui's functions have no way of indicating to the caller that something went wrong, let alone what went wrong.

My current concern is this: in lua, signalling an error involved setjmp/longjmp. When building the bindings for the table library, I found that there may be cases when the functions that make up the tablemodelhandler may need to signal an error to the main application. However, this involves jumping over stack frames that may belong to libui, or worse, the underlying system ui code (for the record, the same thing may occur with other callback functions).

I don't really know how to solve this, but I think it would be helpful if I could signal an error from the callback functions to the maib library that may then somehow be retrieved by the embedding application (or language binding, or whatever).

[andlabs]

Do you mean errors fetching data or errors that happen in the GUI library itself? And what should happen if an error is returned? For instance, libui doesn't know if a call to SetCellValue changed anything or not; it just unconditionally calls CellValue afterward, so an error in SetCellValue should ideally have no effect on the value that was already there... And does lua not have a way to make a local setjmp/longjmp chain (or exception handler try block, or whatever you call it)? Throwing exceptions across library boundaries is generally frowned upon for the reason you described above.

[gnarz]

My immediate concern are errors in callbacks, but errors in the library itself are also not communicated to the caller. I try to catch as many of these as I can before even calling into libui, making sure that everything is valid when calling into libui (as far as that is possible).

I currently call the lua callbacks using a safe mechanism that also catches any errors, so that they will not be thrown across library boundaries. But the result of this is that any errors in callbacks are lost.

[andlabs]

What kinds of errors does Lua have that can be communicated back to the caller of a function by another library? I'm not sure I understand what's being asked for on that front (errors in the callbacks).

For libui's own errors, libui does need better error handling for programmer errors, whicha re ideally the only kinds of errors that libui could report. GTK+ and macOS don't have mechanisms for catching other types of errors that could happen.

[gnarz]

lua is a dynamic, interpreted language, so all kinds of errors may occur in the callbacks, like mistyped variable names, invalid computations and other stuff. Programmer errors, really, as you say.

Basically I want to communicate any such errors back to the lua top level, but the standard error mechanism can't be used for that (because of the aforementioned longjmp issues). I thought it might be useful to have a mechanism to bounce such errors through libui somehow, but have really no idea how that could work. I think, however, that this might be a common issue for language bindings.

[parro-it]

We had the same error propagation problem with callbacks in Node.js binding.

In native node binding, we can throw two kind of exception: normal ones, that propagate on the stack as usual, and fatal exceptions, that are reported in console and then terminate the running process.

The user is still able to catch fatal exception by subscribing to a special Node uncaughtException event.

We raise fatal exception if there is an exception thrown by a user callback.

I don't know lua very well, but maybe it has a similar concept? Or if it hasn't, I guess you can write an 'uncaughtException' event yourself and just raise it passing the error description?

[parro-it]

For libui's own errors, libui does need better error handling for programmer errors

I think that could be a really useful addition to the library