Error handling

[Joseph Reynolds]

On 7/20/23 2:04 AM, chandu chanti wrote:
> Hi Team, We are planning to handle errors from backend services in bmc 
> web. We are considering the following approaches to implement it, but 
> we are facing some issues. please provide your inputs. 1 . Using 
> exceptions in our backend D-Bus service
> ZjQcmQRYFpfptBannerStart
> This Message Is From an Untrusted Sender
> You have not previously corresponded with this sender.
> Report Suspicious
> <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/PjiDSg!12-vrJJyaRL1Nus7N26ProiLa90y_FB6oawxkmvrT4YcN373bBkdTP-XPRTFLRBygswzt1TwX0wxp5Tel83pR4ZZR-wpxEYJpcKudcTfq2FH6iPLN9Ep4cV_tX4$> 
>
> ZjQcmQRYFpfptBannerEnd
>
> Hi Team,
>
> We are planning to handle errors from backend services in bmc web. We 
> are considering the following approaches to implement it, but we are 
> facing some issues. please provide your inputs.
>

I didn't see anyone else answer this.  Is your question about how to 
architect or design your D-Bus interfaces?  Is the reference the BMCWeb 
merely to provide context as a consumer of these D-Bus services?  I 
assume so.

I don't have any special insights.  Are you looking to follow a design 
pattern?  Are you looking for direction from the BMCWeb maintainers?

Joseph

> 1 . Using exceptions in our backend D-Bus service by throwing 
> exceptions in the D-Bus property get handlers. It works fine for the 
> Get property method call. However, when using the Get All method call, 
> if one property fails, an error is returned without checking the other 
> properties. Is there a way to implement exceptions in GetAll so that 
> even if one property fails, we can still fetch the remaining properties.
>
> 2. Using default values in D-Bus properties to indicate errors. Is 
> there a reference implementation available for setting default values 
> for string and integer data types in bmc web, similar to the 
> implementation of NaN (default value) for the double data type in 
> cable.hpp.
>
> 3. Implement associated return code per property on dbus, but this 
> would be very inefficient in terms of double the properties on dbus, 
> something we would like to avoid
>
> Thanks
> Chandrasekhar T.
>