airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Saminda Wijeratne <samin...@gmail.com>
Subject Re: Conveying Errors through the Thrift API
Date Thu, 24 Apr 2014 16:24:16 GMT
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 <marpierc@iu.edu> 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: 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