#119 new
Martin S.

Refactor error code semantics

Reported by Martin S. | April 7th, 2010 @ 08:24 AM | in 1.4.0 Release

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.

Comments and changes to this ticket

  • Martin S.

    Martin S. April 20th, 2010 @ 11:11 AM

    Bryan Forbese has created a branch which uses GError:

    + 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...).

  • Martin S.

    Martin S. June 9th, 2010 @ 10:22 AM

    • 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.

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.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

A project around supporting the iPhone in Linux.

See http://libimobiledevice.org

People watching this ticket