I think #2 is more appropriate and more aligned with Error Classification discussion[1]. It will allow us to map the error messages based on gateway and send more user friendly errors to the clients.
About the API version, i think its a minor version increment than going to the patch route (i hate ubuntu patches). 1. https://docs.google.com/document/d/1jxkb9kM40JBi9JJ-fxmVLcf_8219WfMlngPd8WrL4a0/edit Thanks Raminder On Apr 24, 2014, at 12:30 PM, Marlon Pierce <[email protected]> wrote: > I think if we can't maintain backward/forward compatibility with Thrift > as we uncover more error conditions, then we have to go with Option 2. > > On a side note, I have a semantic versioning question. If we make > changes to the API that are backward compatible, then this is a minor > version increment (x.y+1.0) or a patch update (x.y.z+1)? > > Marlon > > On 4/24/14 12:24 PM, Saminda Wijeratne wrote: >> hmm... I can agree to the arguments made for both option #1 and #2. IMO If >> we are going for option #1 we need to figure-out type of exceptions as much >> as possible and then make sure atleast the server side is backward >> compatible so that gateways do not need to update their thrift clients and >> their gateway code each time server introduces a new exception. >> >> >> On Thu, Apr 24, 2014 at 10:52 AM, Marlon Pierce <[email protected]> wrote: >> >>> Thanks for the feedback, David. >>> >>> In a more ideal world, we could start with general exceptions and >>> specialize them with more and more specialized error messages without >>> breaking the compatibility of older SDK clients. Does this work in Thrift? >>> >>> Saminda's option #2 puts a burden on the client to process the details >>> of the error message and take some action. This may be the more feasible >>> in practice than Option #1. but Option #1 allows the client to just >>> respond to known exception types. >>> >>> Marlon >>> >>> On 4/24/14 10:55 AM, Reagan, David Michael wrote: >>>> This discussion came out of a particular problem I had with >>> getAllExperimentsInProject(). If you ask for all experiments in a project >>> which doesn't exist, it throws a generic AiravataSystemException. I >>> requested that the exception be more meaningful, so that I can print a >>> message to the user saying "The project you requested doesn't exist." >>>> So, the options Saminda listed, in the case of this particular issue, >>> would be: >>>> 1. Define something like ProjectDoesntExistException >>>> 2. Continue to throw AiravataSystemException, but include something in >>> the exception that would allow me to find out why it was thrown. That way I >>> could write something like: >>>> if ($exception->message == "Project doesn't exist") do something >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Pierce, Marlon >>>> Sent: Thursday, April 24, 2014 9:23 AM >>>> To: [email protected] >>>> Subject: Re: Conveying Errors through the Thrift API >>>> >>>> Hi Saminda, can you explain this in more detail: "We felt that while >>> option 1 is ideal for the requirement it is also unmanageable for both >>> client and server if more and more exception types needs to be introduced >>> over time. " >>>> What kinds of errors are we talking about? What actions should the >>> client take? >>>> >>>> Marlon >>>> >>>> On 4/24/14 3:26 AM, Saminda Wijeratne wrote: >>>>> During an offline discussion related to the JIRA[1], it was made clear >>>>> that in an event of an exception at server side due to >>>>> improper/invalid client requests, the client should get back a proper >>>>> error message which can be programmed against. Two options were >>>>> discussed, >>>>> >>>>> 1. Define exceptions in the thrift data model for each and every >>> error >>>>> that can encounter and use them in the Thrift API >>>>> 2. Define a generic exception in the thrift data model which will >>> have >>>>> tagged data identifying the exception >>>>> >>>>> We felt that while option 1 is ideal for the requirement it is also >>>>> unmanageable for both client and server if more and more exception >>>>> types needs to be introduced over time. Option 2 (while not a >>>>> conventional way of handling error) can circumvent this inconvenience >>>>> by introducing a thrift function to retrieve exact static error >>>>> details (which can be updated at the server side without needing to >>>>> change the thrift model) based on the tagged data. >>>>> >>>>> wdyt? >>>>> >>>>> 1. https://issues.apache.org/jira/browse/AIRAVATA-1142 >>>>> >>> >
