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