tez-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johannes Zillmann <jzillm...@googlemail.com>
Subject Re: 0.5 blockers
Date Tue, 29 Jul 2014 10:53:31 GMT
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 :)


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>
> 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
> >
> >
> > 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.

View raw message