Page MenuHomePhabricator

Eolian error integration
Open, TODOPublic


Eina Error needs to be exposed properly in Eo. There is a lot of possible way to do it. A class could have them defined independently, or it could be along with the error and so document what kind of error to expect from a function call.

cedric created this task.Apr 24 2018, 8:24 AM
cedric triaged this task as TODO priority.
zmike edited projects, added Restricted Project; removed efl.Jun 11 2018, 6:55 AM
q66 removed a project: Restricted Project.Jun 11 2018, 7:37 AM
q66 moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Nov 14 2018, 5:22 AM

The idea is like this:

have a native type error(str).
You can define error like this:

const Efl.Ui.Horrible_Thing : error("something horrible happened");

You then can use that const from the bindings / c. In C this is generated into a function like this:

Eina_Error efl_ui_horrible_thing_get(void) {
static Eina_Error err = eina_error_new("something horrible happened");

In some header we can generate a pre processor token for EFL_UI_HORRIBLE_THING which just calls this functions

The function then can be used from the bindings.

Additionally, it would be good to have something like
return : error_range { Efl.Ui.Horrible_Thing, Efl.Net.Horrible_Thing }; where all passed things are errors. This can be used in the documentation to show which errors are possible.

To have more background, how are errors currently defined and used?

I like @bu5hm4n's proposal, I've seen things defined like this in several places. Do we use this paradigm in other places of EFL?

Regarding the return: error_range, it is not enough to indicate what errors can be returned, it also needs an explanation of what does each error mean. Sometimes it is obvious (E_FILE_NOT_FOUND), but sometimes it is not (E_INVALID_VALUE).

bu5hm4n moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Feb 4 2019, 6:28 AM
q66 added a comment.Jun 24 2019, 6:22 AM

I added an initial syntax for this in the commit above. Please comment if you have any suggestions, objections etc.

I didn't go with the const method as you cannot refer to variables as types and it does not properly match the semantics (a const variable needs to be able to act as a compile-time constant inside expressions, while Eina_Errors are registered at runtime). It did not match global variables all that well either because of the way it will be generated... having a separate set of APIs for it (and its own Eolian unit namespace) makes it easiest to work with.

Generator support is TBD.

Does not compile:

bla.eo.c:3:28: error: initializer element is not constant
    3 |    static Eina_Error err = eina_error_msg_static_register("asdf");
      |                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
error @beta bla = "asdf";
bu5hm4n removed a subscriber: bu5hm4n.Jul 26 2019, 10:13 AM
bu5hm4n added a subscriber: bu5hm4n.
q66 added a comment.Aug 29 2019, 9:12 AM

Hm, what should be do about this? Do we want this to be thread-safe? Because the error API is not...

it's not possible to statically initialize the errors, as eina_error_init needs to be called first

and if we do something like

static Eina_Error ret = EINA_ERROR_NO_ERROR;
if (ret == EINA_ERROR_NO_ERROR) {
    ret = eina_error_msg_static_register("bla");
return ret;

then it'll work but it'll be thread unsafe

q66 added a comment.Sep 6 2019, 9:05 AM

OK, I did that for now, but we'll need to figure out a proper one...