sjelinek wrote: > Hi Evan, > > A couple of comments/questions... > > -I assume the crux of the problem for BE error handling was the > inability to let users know what went wrong when we made calls to other > programs, such as installgrub? Your solution seems geared toward that > type of issue.
It includes this issue but it is general enough to include errors that are internal as well as external. For external errors such as installgrub we can't determine what exactly went wrong and so must tell the consumer to look elsewhere for information (the URL). However for some other external errors (maybe things like zfs_mount) we may have enough that we can determine what the user needs to fix to correct the issue. Also some internal errors we should have enough information to determine what needs to be fixed. In both of these cases we will return that information to the consumer though the structure. It is providing this information that we are really geared toward. > > -Are there issues with error codes for BE functions that need to be > addressed as well? The structure you have defined doesn't appear to > include BE error codes as part of its definition. Is there a need for > this as well, for more general BE errors that do not occur when calling > another program? The way error codes are returned now will not be changed so that consumers will continue to be able to use the same interfaces without things breaking on them. The errors defined in this design will be in addition to what we already have. -evan > > thanks, > sarah > **** >> >> Here is the functional/design spec for the BE error and observability >> project. >> >> It's a first version and does include some design elements for what >> will eventually become the error handling and logging service for the >> Caiman Unified Design project. However this project is not intended to >> provide that error handling and logging but just the beginnings of it >> and the ability to mesh easily with it. >> >> I would like to get any comments by the end of the day on Friday (8/21). >> >> Thanks! >> -evan >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> caiman-discuss mailing list >> caiman-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >
