airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Reagan, David Michael" <dmrea...@iu.edu>
Subject RE: Conveying Errors through the Thrift API
Date Thu, 24 Apr 2014 14:55:05 GMT
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