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 >>>> >>
