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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 > > <[email protected]> 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 <[email protected]> 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. > > > > > >
