airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marlon Pierce <marpi...@iu.edu>
Subject Re: Conveying Errors through the Thrift API
Date Thu, 24 Apr 2014 15:52:27 GMT
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: dev@airavata.apache.org
> 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
>>


Mime
View raw message