+1 for KasunGs suggestion. Even UIExceptions can be different.
*Types of UI errors* - User input errors - App errors - Incompatible state errors IMHO depending on the permission level, above error messages can be optimized to give optimal user experience. Regards, *Dakshika Jayathilaka* PMC Member & Committer of Apache Stratos Associate Technical Lead WSO2, Inc. lean.enterprise.middleware 0771100911 On Wed, Feb 1, 2017 at 12:31 PM, KasunG Gajasinghe <[email protected]> wrote: > > To not disclose the back-end server details to the user, we should always > catch the exceptions in the UUF app. If it is a UIException, then we can > show the error message to the user. Otherwise, we should show a generic > error message - something like "An error has occurred while processing your > request." > > If we know how to handle it, it is best if we handle it within the same > page where the error has occurred. We already do this in multiple places. > For example, see the code for user portal's login page when you enter > invalid credentials. > > For unexpected errors, we can customize the error pages via the app.yaml's > errorPages config. > > app.yaml: > errorPages: > 404: "/foundation/error/404" > 401: "/login" > default: "/foundation/error/default" > > On Wed, Feb 1, 2017 at 12:20 PM, Ayesha Dissanayaka <[email protected]> > wrote: > >> Hi, >> >> What are the good practices around exception handling in UUF in scenarios >> like handling exceptions thrown when callOSGiService. >> >> for example consider below method. >> >>> /** >>> * Check whether the notification based password recovery enabled >>> */ >>> >>> function isNotificationBasedPasswordRecoveryEnabled() { >>> var checkMethod = "isNotificationBasedPasswordRecoveryEnabled"; >>> return callOSGiService("org.wso2.is.p >>> ortal.user.client.api.RecoveryMgtService", >>> checkMethod, []); >>> >>> } >>> >> >> If I don't catch exceptions within this method or whenever using >> *isNotificationBasedPasswordRecoveryEnabled >> *method, in the UI I get below page. >> >> >> What is the recommended way to handle this? >> >> 1. Handle exceptions around callOSGiService. >> - Then we'll have to repeat the same whenever we call osgi from a >> uuf app >> 2. Handle at method invocation, and redirect to error page. >> 3. Provide a generic message in the UI from UUF in such cases, unless >> handled in the app. >> 4. Do we have to handle exceptions from osgi service itself? >> 5. Other? >> >> Thanks! >> -Ayesha >> >> -- >> *Ayesha Dissanayaka* >> Software Engineer, >> WSO2, Inc : http://wso2.com >> <http://www.google.com/url?q=http%3A%2F%2Fwso2.com&sa=D&sntz=1&usg=AFQjCNEZvyc0uMD1HhBaEGCBxs6e9fBObg> >> 20, Palmgrove Avenue, Colombo 3 >> E-Mail: [email protected] <[email protected]> >> >> _______________________________________________ >> Dev mailing list >> [email protected] >> http://wso2.org/cgi-bin/mailman/listinfo/dev >> >> > > > -- > > *Kasun Gajasinghe*Associate Technical Lead, WSO2 Inc. > email: kasung AT spamfree wso2.com > linked-in: http://lk.linkedin.com/in/gajasinghe > blog: http://kasunbg.org > phone: +1 650-745-4499 <(650)%20745-4499>, 77 678 0813 > > > _______________________________________________ > Dev mailing list > [email protected] > http://wso2.org/cgi-bin/mailman/listinfo/dev > >
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
