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. April 20th, 2010 @ 11:11 AM
Bryan Forbese has created a branch which uses GError:
http://github.com/bryanforbes/libiphone/tree/gerrorPro/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...). -
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.
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
Martin S.