 |
 |
> This has been a problem in layered APIs. A great example is Mozilla > libldap + Cyrus SASL + MIT or Heimdal gss/krb5 -- all GSS errors tend to > get aliased into one libldap error. This is a case with _five_ layers > (SASL is two layers, and GSS is two more). Yes, and I'm dealing internally with at least that many layers in my own code. There are also specific requirements to *prevent* errors from being seen because there's client-side failover support for SAML queries when the authority advertises multiple endpoints. And there's chaining of attribute sources themselves on top of that. The solution here is to decorate the normal API for resolving attributes with optional status information from the underlying components. > The first problem is dealing with the error handling limitations of each > layer, which often requires extensive surgery (and API extensions) or > outright new APIs (too much work). The second is that often apps can > only pass detailed error information to users, as opposed to acting on > detailed error information to remediate the situation (often there's > nothing they could do to remediate the situation). But one must not > underestimate the value of making detailed error information available > to the user. No, but one must not overestimate it either. It needs to be visible, but to the person resolving the problem, not necessarily to the user. In this case, it's always visible in my logs, but I can add some additional bandwidth to my APIs if people want to do more. -- Scott