feat: Introduce Zig error handle

[GlowingUmbreon]

Adds some error handling.
Not all functions have been completed, I have focused on the functions that are easier to handle errors for and added TODO comments in places which require some further thought.

In particular the interfaceGet functions will be be harder to detect errors for as they could either be valid inputs or it could be a error.

[AlbertShown]

Will examples still work without try ?

[GlowingUmbreon]

Will examples still work without try ?

Nope, zig enforces that you must handle errors. I added some a note about this in #91.
This change would likely need to be on a major release as it is a breaking change

[AlbertShown]

I see, well, webui and zig-webui v2.5 is the next coming major version, so now it's the best time to do any breaking changes.

However, I will let @jinzhongjia to test and decide.

[jinzhongjia]

great work
But I noticed that the error types are actually declared only two, which is too vague and the theory should add more error types
Let me do the rest of the work

[GlowingUmbreon]

@jinzhongjia Thats fine.

The reason for the two errors are because webui does not return any errors itself it just returns that something went wrong so I cannot confirm as to what caused the error hence the "Generic Error".
Will you be implementing the changes in your own PR? If so feel free to close this PR.

[jinzhongjia]

I will probably modify it directly on your pr. Different functions have different meanings, and it should return different errors

[AlbertShown]

@jinzhongjia He used a generic error because webui returns only true or false.

To solve this, I will implement in webui webui_get_last_error(), so can be optional, without any breaking changes, like this:

const char* WEBUI_ERRORS_LIST[] = {
    "WebUI not initialized",
    "Server not found",
    "Parameter is missing",
    "File not found",
    "Web browser not found",
    ...
}

if ( ! webui_new_window() ) {
    int error_number = webui_get_last_error_number();
    printf ("Error: %s", WEBUI_ERRORS_LIST[error_number]);
}

Or even simpler version:

if ( ! webui_new_window() ) {
    printf ("Error: %s", webui_get_last_error_message());
}

[AlbertShown]

@jinzhongjia, @GlowingUmbreon, what do you think?

[GlowingUmbreon]

That looks good and will allow for detecting the type of error. Will it return just a string or will it also return a numeric ID of the error?

[AlbertShown]

I think we need both of them, id and message string, so wrappers can use it as needed.
For Zig it should be something like this:

// WebUI Error Handler

pub const WebUIError = error {
    GenericError,
};

pub const WebUIErrorInfo = struct {
    num: i32,
    msg: [:0]const u8,
};

pub fn getLastError() WebUIErrorInfo {
    return .{
        .num = c.webui_get_last_error_number(),
        .msg = c.webui_get_last_error_message(),
    };
}

// WebUI APIs

pub fn newWindow() WebUIError!webui {
    if (c.webui_new_window()) {
        return .{ .window_handle = c.webui_new_window() };
    }
    return WebUIError.GenericError;
}

Usage:

const window = webui.newWindow() catch |err| {
        const error = webui.getLastError();
        std.debug.print("WebUI Error {d}: {s}\n", .{ error.num, error.msg });
        return;
};

That's all what wrappers have to do, webui will take care of providing error id and error description message.

[AlbertShown]

In this way all Zig examples are not forced to use try and catch, if API call succeed then all will work fine...
otherwise, the developer can add try and catch to avoid app crash when an API fails.

[jinzhongjia]

Great idea

[AlbertShown]

Initial implementation (webui-dev/webui@2cb977f).
This Zig PR can be updated now to reflect this new error handling.

@GlowingUmbreon Thank you for the suggestion 👍

[jinzhongjia]

@AlbertShown @hassandraga
webui c lib webui_bind , What value of the returned bind id represents invalidity

[jinzhongjia]

I have also made some fixes, but there are some problems with the current binding function, I will make an extra pr fix later

[jinzhongjia]

@AlbertShown
@hassandraga
I think the current example covers the functions that are not enough. They are not only examples, but also should exist as unit tests.

[AlbertShown]

webui c lib webui_bind , What value of the returned bind id represents invalidity

What do you mean? webui_bind() returns a unique ID.

but also should exist as unit tests.

We can add auto test when we release the last beta before release.

[jinzhongjia]

webui_bind()
So that means there will be no situation where the id cannot be assigned, right? As long as the value is returned, the id will be valid.

[AlbertShown]

webui_new_window() return a window ID, used by user code to identify a window int myWindow. User can set his own ID using webui_new_window_id(123).

webui_bind() return a unique internal webui ID, used by wrappers to identify a bind if needed, like int bind_index. User can not set an ID.