You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tez.apache.org by Siddharth Seth <ss...@apache.org> on 2014/07/30 07:54:56 UTC
Re: Exceptions on Tez APIs
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 <ss...@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 <bi...@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.
> >
> >
>
>
Re: Exceptions on Tez APIs
Posted by Siddharth Seth <ss...@apache.org>.
Yes, the same can easily be achieved via unchecked exceptions.
Having explicit exceptions forces users to think about how errors need to
be handled, and hopefully read the Javadocs to figure out what the error
scenarios are.
For people just experimenting with Tez - the exceptions are a nuisance,
which probably just end up getting ignored. For products which make use of
Tez in production for example, there are some important exceptions which
should be handled, and potentially translated into product specific error
messages.
We should likely do a review of the exceptions, and see if we can get rid
of them on at least some of the APIs.
On Wed, Jul 30, 2014 at 7:04 AM, Johannes Zillmann <jzillmann@googlemail.com
> wrote:
> I understand, but the same could be achieved with an unchecked exception,
> right ?
> Unless the user figures out it makes sense to handle the
> SessionNotRunning, does it provide any benefit having a checked
> TezException ?
>
> Johannes
>
> On 30 Jul 2014, at 07:54, Siddharth Seth <ss...@apache.org> wrote:
>
> > 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 <ss...@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 <bi...@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.
> > >
> > >
> >
> >
>
>
Re: Exceptions on Tez APIs
Posted by Siddharth Seth <ss...@apache.org>.
Yes, the same can easily be achieved via unchecked exceptions.
Having explicit exceptions forces users to think about how errors need to
be handled, and hopefully read the Javadocs to figure out what the error
scenarios are.
For people just experimenting with Tez - the exceptions are a nuisance,
which probably just end up getting ignored. For products which make use of
Tez in production for example, there are some important exceptions which
should be handled, and potentially translated into product specific error
messages.
We should likely do a review of the exceptions, and see if we can get rid
of them on at least some of the APIs.
On Wed, Jul 30, 2014 at 7:04 AM, Johannes Zillmann <jzillmann@googlemail.com
> wrote:
> I understand, but the same could be achieved with an unchecked exception,
> right ?
> Unless the user figures out it makes sense to handle the
> SessionNotRunning, does it provide any benefit having a checked
> TezException ?
>
> Johannes
>
> On 30 Jul 2014, at 07:54, Siddharth Seth <ss...@apache.org> wrote:
>
> > 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 <ss...@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 <bi...@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.
> > >
> > >
> >
> >
>
>
Re: Exceptions on Tez APIs
Posted by Johannes Zillmann <jz...@googlemail.com>.
I understand, but the same could be achieved with an unchecked exception, right ?
Unless the user figures out it makes sense to handle the SessionNotRunning, does it provide any benefit having a checked TezException ?
Johannes
On 30 Jul 2014, at 07:54, Siddharth Seth <ss...@apache.org> wrote:
> 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 <jz...@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 <ss...@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 <jz...@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 <bi...@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.
> >
> >
>
>
Re: Exceptions on Tez APIs
Posted by Johannes Zillmann <jz...@googlemail.com>.
I understand, but the same could be achieved with an unchecked exception, right ?
Unless the user figures out it makes sense to handle the SessionNotRunning, does it provide any benefit having a checked TezException ?
Johannes
On 30 Jul 2014, at 07:54, Siddharth Seth <ss...@apache.org> wrote:
> 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 <jz...@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 <ss...@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 <jz...@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 <bi...@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.
> >
> >
>
>