Mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Siddharth Seth <ss...@apache.org>
Subject Re: Exceptions on Tez APIs
Date Wed, 30 Jul 2014 05:54:56 GMT
That's a perpetual debate. The approach that Tez is following, is similar
to YARN - where the client APIs throw a checked exception local to the
framework and an IOException.
The IOException is something which indicates an error in the RPC layer.
This isn't always actionable - but could potentially be useful for retries.
TezException serves two purposes - one is to serve as a placeholder for any
exceptions which may need to be thrown in the future, which are useful to
users. The second is for users to actually handle exceptions and take some
action - an example is SessionNotRunning - in which case they can try
re-starting the session.


On Tue, Jul 29, 2014 at 3:53 AM, Johannes Zillmann <jzillmann@googlemail.com
> wrote:

> Hey Sid,
>
> in my experience adding checked exception to a project (and i did it a
> lot) doesn’t really add any benefit.
> Using the project just becomes tougher. Ok, its throwing a TezException
> and i have to handle this. So what does that mean ? Usually its worthless
> and just adds overhead until you run into some specific cases, like ok i
> need to handle this TezTimeoutException separately. But the same thing you
> can easily do with an unchecked exception.
>
> So frankly i’m all against checked exceptions ;)
> However, oracle/sun is saying:
>         "Here's the bottom line guideline: If a client can reasonably be
> expected to recover from an exception, make it a checked exception. If a
> client cannot do anything to recover from the exception, make it an
> unchecked exception.”
>
> So looking at the Tez code base the TezException is all over the place.
> And how said its not obvious for an user what the TezException could be and
> how to handle it.
>
> All in all nothing dramatic.. but would just like it more if it would be
> unchecked :)
>
> Johannes
>
>
> On 29 Jul 2014, at 09:43, Siddharth Seth <sseth@apache.org> wrote:
>
> > Johannes
> > Is there some specific API which throws a TezException, and where you
> think a RuntimeException would be sufficient ? Trying to understand why
> you'd like to change TezException to be a RuntimeException.
> >
> > Thanks
> > - SId
> >
> >
> > On Mon, Jul 28, 2014 at 11:18 PM, Johannes Zillmann <
> jzillmann@googlemail.com> wrote:
> > https://issues.apache.org/jira/browse/TEZ-1278 with its current
> solution will change the API, so please consider that!
> >
> > Also btw, did you consider making TezException a RuntimeException ?
> >
> > best
> > Johannes
> >
> > On 25 Jul 2014, at 04:21, Bikas Saha <bikas@hortonworks.com> wrote:
> >
> > > Folks,
> > >
> > > Here are the blockers for 0.5.
> > >
> https://issues.apache.org/jira/browse/TEZ-1311?jql=project%20%3D%20TEZ%20AND%20resolution%20%3D%20Unresolved%20AND%20priority%20%3D%20Blocker%20ORDER%20BY%20key%20DESC
> > >
> > > Please add to the list in case something is missing. Only API
> stability issues should make it to the blocker list since 0.5 is expected
> to be an API stable release. Addition of a API’s is possible after 0.5. So
> new API’s don’t need to be included in this list.
> > >
> > > Thanks
> > > Bikas
> > >
> > >
> > > CONFIDENTIALITY NOTICE
> > > NOTICE: This message is intended for the use of the individual or
> entity to which it is addressed and may contain information that is
> confidential, privileged and exempt from disclosure under applicable law.
> If the reader of this message is not the intended recipient, you are hereby
> notified that any printing, copying, dissemination, distribution,
> disclosure or forwarding of this communication is strictly prohibited. If
> you have received this communication in error, please contact the sender
> immediately and delete it from your system. Thank You.
> >
> >
>
>

Mime
View raw message