Jan Damborsky wrote: > 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 ?
This was done specifically to allow for extensibility. If this was just one structure it would be difficult to make this extensible without breaking already existing consumers should we add another type to the structure (what is now the union). > > * 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 :-) Perhaps for logging but for the error handling any exceptions should be handled by the consumer since that would be where the context > > * 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 ? Normally this may be the case and for libbe this may be true but for things like AI I can see a situation where there may be an EI_ERR for both AI and libtd. For enumerating through these errors, since this is a linked list the consumer can either go though all of the errors or can retrieve them by type using the provided interfaces. > > * 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. Since I did provide something similar already for libbe maybe what would be more help is an example for AI itself. I'll get with Ethan and see if we can come up with something for AI. -evan
