Some other points for changing them to inherit from RuntimeException: - Just design-wise, having to add a declared exception to all callers of functions that contain RPC calls leaks implementation details. - Declared exceptions for RPC calls also cause tighter coupling to Thrift. Now, if you wanted to replace the RPC calls with a different framework, you have to change all the method signatures containing the declared exception. - As mentioned, you can also just use a try-catch around all the RPC calls. However, not only is it tedious and ugly, you usually don't have the context within the client call to even do anything about it besides return null or something. For example, it would be hard to try to re-establish the connection within the scope of the call.
I have no experience with working on the java thrift lib, and it may take me some time to get up to speed. But, I can maybe try to get to this in the next few months or so if nobody has strong objections to making this change. On Thu, Sep 3, 2015 at 8:58 AM, Randy Abernethy <[email protected]> wrote: > Hey All, > > In Java TException is derived from the java Exception class. Per the Java > docs: > > >> The class Exception and its subclasses are a form of Throwable that > indicates > >> conditions that a reasonable application might want to catch. > > Sounds like what we want. > > >> The class Exception and any subclasses that are not also subclasses of > >> RuntimeException are checked exceptions. Checked exceptions need to be > >> declared in a method or constructor's throws clause if they can be > thrown by > >> the execution of the method or constructor and propagate outside the > method > >> or constructor boundary. > > So changing to RuntimeException as a base would make TException silently > throwable in Java, (which is the proposal). > > In Apache Thrift, user defined exceptions which can be thrown from the > server > back to the client could then easily go uncaught. Also > TApplicationExceptions > which can always be thrown by a thrift server back to a client (even if the > user > doesn't define exceptions) could leak through. While I'm not a big fan of > Java > syntax, if your going to code in Java it seems like declaring throws > TException > is not a huge (or at least unusual) burden. In the greater scheme on things > making > an RPC call is a risky operation. > > I was against this proposal until I began looking for idiomatic Java > behavior in > this area, where I found several examples using RuntimeException as the > base. > For example the javax.ws.rs.client.Invocation.invoke() method (used to make > REST calls in JAXRS) throws ResponseProcessingException which is unchecked. > > java.lang.Object > java.lang.Throwable > java.lang.Exception > java.lang.RuntimeException > javax.ws.rs.ProcessingException > javax.ws.rs.client.ResponseProcessingException > > So while I personally like the checked approach it seems we would be more > inline with common practice if we switch to RuntimeException as a base. > > +0.5 > > -Randy > > On Thu, Sep 3, 2015 at 2:45 AM, Jens Geyer <[email protected]> wrote: > > > Some of the other languages actually do that. What about providing a > patch? > > ________________________________ > > Von: J > > Gesendet: 02.09.2015 21:38 > > An: [email protected] > > Betreff: Why isn't TException a subclass of RuntimeException in Java? > > > > It seems tedious to have to mark every method that does a thrift rpc call > > with "throws TException" or have to put a try-catch around every call. > Why > > wasn't TException made a subclass of RuntimeException? I think many RPC > > implementations I've used usually make the rpc/proxy errors runtime > > exceptions. There usually isn't anything you can do about it locally in > the > > client call anyway. > > >
