List:Backup« Previous MessageNext Message »
From:Ingo Strüwing Date:October 27 2009 9:11am
Subject:Re: RFC: WL#5046 - error reporting
View as plain text  
Hi Rafal, Andreas,

Rafal Somla, 27.10.2009 09:35:

...
> Andreas Almroth wrote:
...
>> Error codes must be standardized in the BSM API as else there would be
>> no way for the backup kernel to decide whether to abort, continue or
>> act on error.
> 
> My idea is that if BSM reports error, then it is a fatal error and BSM
> can not be used after that. Any "non-fatal error", after which BSM can
> continue to serve the user, is not reported as an error but is signalled
> as a valid reply from a service.
> 
> For example, if service S10 is called to get information about backup
> image but the location does not contain any data, this is signalled in a
> reply from the service which completes successfully. This is so because
> after such situation the storage session is still usable and the user
> can e.g., create a new image at this location.
> 
> In such design, the only sensible thing which backup kernel can do when
> BSM signals error is to report it and abort. If other action is
> possible, this would depend on the context in which BSM was called. Thus
> I don't see it necessary that errors reported by BSMs must be
> interpreted by its user.


As mentioned in an earlier message, I am more with Andreas. Your design
proposal requires to foresee all non-fatal errors. If a new one arises
later, we need to change the interface.

...


Regards
Ingo
-- 

Ingo Strüwing, Database Group
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Geschäftsführer: Thomas Schröder,   Wolfgang Engels,   Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin Häring   HRB München 161028
Thread
RFC: WL#5046 - error reportingRafal Somla24 Oct
  • Re: RFC: WL#5046 - error reportingIngo Strüwing25 Oct
    • RE: RFC: WL#5046 - error reportingAndreas Almroth26 Oct
    • Re: RFC: WL#5046 - error reportingRafal Somla27 Oct
      • Re: RFC: WL#5046 - error reportingIngo Strüwing27 Oct
        • Re: RFC: WL#5046 - error reportingRafal Somla28 Oct
          • Re: RFC: WL#5046 - error reportingIngo Strüwing29 Oct
            • Re: RFC: WL#5046 - error reportingRafal Somla3 Nov
              • RE: RFC: WL#5046 - error reportingAndreas Almroth4 Nov
  • Re: RFC: WL#5046 - error reportingRafal Somla27 Oct
    • Re: RFC: WL#5046 - error reportingIngo Strüwing27 Oct
      • Re: RFC: WL#5046 - error reportingRafal Somla27 Oct
        • RE: RFC: WL#5046 - error reportingAndreas Almroth27 Oct
  • Re: RFC: WL#5046 - error reportingIngo Strüwing4 Nov