+1 for having custom exceptions. However, as Malintha mentioned I believe it will help us having exception hierarchy. There may be cases where catching top level exceptions may be sufficient. If we have a hierarchy, programmer can decide which one to use depending on the context.
Thanks Susinda On Fri, Oct 21, 2016 at 12:26 PM, Isuru Perera <[email protected]> wrote: > +1 for having separate exception classes. It's also good if you want to > define different hierarchies of exceptions, but we need to think carefully > and properly group those exceptions. > > > > On Fri, Oct 21, 2016 at 12:08 PM, Harsha Kumara <[email protected]> wrote: > >> >> >> On Fri, Oct 21, 2016 at 11:14 AM, Malith Jayasinghe <[email protected]> >> wrote: >> >>> Hi Harsha, >>> >>> It makes sense to define specific exceptions. However, I am wondering >>> (in most of these cases) whether the caller can do anything specially to >>> handle these exception (I guess this will depend on how you define the >>> exception (and when it will be thrown)? >>> >>> For example, if you throw APIMDAOException when you get a SQL exception >>> within a DAO method, how would the client code handle it? Can you give an >>> example? >>> >> Basically if we find a exception in DAO layer, let's say if we going to >> search users by name and it returns a SQL exception, we need catch it and >> throw defined exception with error message saying it's failed when >> searching users. In upper layers it will be useful. Also DAO layer may not >> only throw SQL exceptions, there might me different types of exceptions >> thrown from it. In service layer it might not need to aware all about it. >> We shouldn't expose DAO layer exceptions for end users as well. Because DAO >> layer exceptions might contains information regarding queries, schema and >> etc. Also with having defined exception we can send response back to the >> client accordingly. If we encounter server error we may return 404 while if >> we encounter security exception we may send response with other error >> accordingly. >> >> [1] http://tutorials.jenkov.com/java-exception-handling/exce >> ption-wrapping.html >> >>> >>> Thanks >>> >>> Malith >>> >>> >>> >>> On Thu, Oct 20, 2016 at 3:31 PM, Harsha Kumara <[email protected]> wrote: >>> >>>> Definitely we need to have well defined set of exceptions instead using >>>> APIManagementException in all places. As Uvindra mentioned, for API Manager >>>> database access, we can have APIMDAOExcepton. For security related >>>> exceptions we can have APIMSecurityException and so on. In jaggary level >>>> also we check the instance type of a thrown exception and return responses >>>> accordingly. >>>> >>>> [1] http://howtodoinjava.com/best-practices/java-exception-h >>>> andling-best-practices/ >>>> >>>> On Thu, Oct 20, 2016 at 2:27 PM, Uvindra Dias Jayasinha < >>>> [email protected]> wrote: >>>> >>>>> I would like to know your thoughts on $subject. >>>>> >>>>> Previously we have a single custom exception class in APIM called >>>>> 'APIManagementException' and this was used when throwing exceptions >>>>> specific to the APIM product. Pros and Cons of doing it this way are, >>>>> >>>>> *Pros* - Only one APIM specific exception needs to be handled in the >>>>> entire APIM code base >>>>> >>>>> *Cons* - When an exception is thrown its very difficult to pin point >>>>> the reason for the exception to be thrown. This results in, >>>>> >>>>> 1. Having to solely depend on the error message of the exception to >>>>> determine what has happened(Provided that the error message is clear) >>>>> >>>>> 2. Difficult to handle exception appropriately at code level because >>>>> we are not aware of the specifics of the exception >>>>> >>>>> >>>>> In light of this doesn't it make sense to define specific custom >>>>> exceptions? For example when interacting with the DAO component of APIM if >>>>> any data access errors are encountered we could define an >>>>> 'APIMDAOException' and throw that. This allows users of the DAO component >>>>> to clearly identify and handle that specific exception appropriately. >>>>> >>>>> >>>>> This obviously needs to be applied in a way that makes sense at >>>>> component level(DAO, Gateway, etc.) so its clear which specific component >>>>> has run into an issue. >>>>> >>>>> WDYT? >>>>> >>>>> -- >>>>> Regards, >>>>> Uvindra >>>>> >>>>> Mobile: 777733962 >>>>> >>>> >>>> >>>> >>>> -- >>>> Harsha Kumara >>>> Software Engineer, WSO2 Inc. >>>> Mobile: +94775505618 >>>> Blog:harshcreationz.blogspot.com >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Malith Jayasinghe >>> >>> WSO2, Inc. (http://wso2.com) >>> Email : [email protected] >>> Mobile : 0770704040 >>> Lean . Enterprise . Middleware >>> >> >> >> >> -- >> Harsha Kumara >> Software Engineer, WSO2 Inc. >> Mobile: +94775505618 >> Blog:harshcreationz.blogspot.com >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Isuru Perera > Associate Technical Lead | WSO2, Inc. | http://wso2.com/ > Lean . Enterprise . Middleware > > about.me/chrishantha > Contact: +IsuruPereraWSO2 <https://www.google.com/+IsuruPereraWSO2/about> > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Susinda Perera* Software Engineer B.Sc.(Eng), M.Sc(Computer Science), AMIE(SL) Mobile:(+94)716049075 Blog: susinda.blogspot.com WSO2 Inc. http://wso2.com/ Tel : 94 11 214 5345 Fax :94 11 2145300
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
