Lighthouse has a new layout. Prefer the old one? Return to the old layout, and switch back any time from the link at the top of each page.

Refactor error code semantics

#119

During the 1.0 API change we came across issues with the current error system.
Some error codes appear shared and others inconsistent. Errors from inherited namespaces are not properly leveraged to the calling function but rather shadowed by introducing new error codes in the same namespace (like the E_MUX_ERROR). Implementations have to deal with a range of error codes correctly, especially if using several services.

The overall feeling is that the error reporting is not yet good enough.

Reported by Martin S. · April 7th, 2010 @ 08:24 AM

State: new
Milestone: 1.4.0 Release
Assigned to: nobody

Activity

  1. Martin S.
    Martin S.

    Bryan Forbese has created a branch which uses GError:
    http://github.com/bryanforbes/libiphone/tree/gerror

    Pro/Cons:
    + Allows error "bubbling/propagation" + Propagation might allow to normalize some error domains - Changes whole API ~ Further moves us to directly use glib overall (GObject, GError, etc.)

    Feedback or other ideas welcome.

    What I would make the decisive argument is how well one's implementation looks if it has to deal with errors.
    With the current error system, implementations have to check for various error macros, one has to know the macro names and to make it hard we also have error domains to check (AFC_E_SUCCESS vs. NP_E_SUCCESS vs. LOCKDOWND_E_SUCCESS...).

    April 20th, 2010 @ 11:11 AM

  2. Martin S.
    Martin S.
    • Milestone changed from 1.2.0 Release to 1.4.0 Release

    Moving to 1.4.0 milestone for now as we are approaching 1.2.0.

    June 9th, 2010 @ 10:22 AM

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.