Evan Layton wrote: > >>> >>> [2] It is mentioned that the error structure will contain at least >>> following information: >>> * failure type >>> * failure ID (error number) >>> * where the failure happened >>> * what went wrong >>> * how to fix it (if possible) or report it >>> >>> How this information will map to the proposed err_info and err_data >>> structures ? >>> >>> [3] To be honest, I don't quite understand how the error service >>> will be plugged into the overall infrastructure - how the process >>> and >>> data flow will look like - I think it might be useful to provide >>> some kind of 'case study' or example - e.g. how libbe is going to >>> consume it in particular failure scenario. >>> >> >> I think what may be helpful here in addition to an example from libbe >> or AI would be a drawing that shows how all this fits together. I'll >> create this and attach it to the design as well as adding a couple of >> examples. I think for examples it might be best to add one for libbe >> as well as one for AI. >> > > In an attempt to address these two issues, I've created some images > that show what the structures might look like as well as written up a > very brief example of what some of the calls _might_ look like for > setting and getting error data.
Thank you ! Looking at the example and picture, I have now better idea how things are supposed to work. Now I have additional questions :-) * since all strings (EI_OP_STR, EI_FIXIT_STR, ...) along with error code are attributes of one error object, why not to encapsulate them all in one structure instead of creating linked list ? * Should we consider to define some kind of exception handler or callback method for each error type (EI_ERR, ...) which would be invoked when new error is registered ? This would allow grouping the steps which are common to processing particular error and specifying them in one place - e.g. logging, displaying strings on console or beep :-) * speaking about error types, it is mentioned that it is assumed that only one EI_ERR will be captured, but multiple instances of clean-up and resolved errors might be provided. In case there are more errors of particular type, how will consumer enumerate through them ? * Could you please provide examples of particular error types mapping to real libbe failures ? This might help to envision how this concept would be applied in AI case. Jan
