We are working on a suite of mobile applications, and a (potentially) 3rd party accessible API.
The current error mechanism in AspNetZero, is fine - but a little opaque. Making client-side decisions based on the error information provided is not reliable - for several reasons.
- returned errors are often only differentiated by their message, which is fine for providing an explanation to the user, but no good for making application flow decisions. e.g, AbpAuthorizationException can be returned for several reasons - tenant disabled, user account inactive, incorrect username/password, etc etc. I don't want to be parsing localized error messages in a client, to make application flow decisions.
- HTTP result codes are course in their granularity, again making it impossible to handle specific scenarios to improve user experience
the ErrorInfo object returned in the AjaxResponse does have a "code" - but I have never seen it used/populated by ANZ. I can see that I only need to throw an exception that implements IHasErrorCode, to populate the "code" field - such as with "UserFriendlyException".
To my questions:
- I figured all the above out myself, because there is no documentation under AspNetZero or AspNet Boilerplate. The "abp.io" product does document, what I can only assume is something similar, however, as ANZ/Boilerplate customers, we generally avoid ABP.io documentation as the product is different, and it can lead us astray.
- Can we see the ANZ/ABP products better adopt this "code" field? I would like to see a const list of known exception cases and codes in the application server code - which would enable client applications to move to toward a functional error-handling practice, and avoid missing exception scenarios.
Of course - ANZ getting ABP.IO business-exception subsystem would be fantastic... https://docs.abp.io/en/abp/latest/Exception-Handling