airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marlon Pierce <>
Subject Re: Conveying Errors through the Thrift API
Date Thu, 24 Apr 2014 16:30:48 GMT
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)?


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

View raw message