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
>
