Comcast / sirius

A distributed system library for managing application reference data
http://comcast.github.io/sirius/
Apache License 2.0
298 stars 49 forks source link

SiriusResult should wrap Throwable (issue #8) #25

Open smuir opened 10 years ago

smuir commented 10 years ago

There's no particular reason why SiriusResult can only wrap RuntimeException as an error, so generalise it to Throwable (analogous to the Scala Try class).

See https://github.com/Comcast/sirius/issues/8

comcast-jonm commented 10 years ago

There's another backwards-compatibility angle here, which is that old client code looking like this:

SiriusResult result = ...;
if (result.isError()) {
  try {
    result.getValue();
  except (RuntimeException re) {
    /* this catches everything that can be thrown here */
  }
}

May get a subtle surprise if a SiriusResult somehow shows up with a checked exception or an Error.

However, I am +1 on this being part of a revamped 1.2 interface, which I'll get around to adding shortly.

smuir commented 10 years ago

For that to be an issue in practice it would require that somehow existing code managed to get a superclass of RuntimeException wrapped in a SiriusResult. Is that possible? A backwards-compatible solution might be to not change the error(RuntimeException) factory method, but add an alternative used to wrap Throwable

smuir commented 10 years ago

Anyway, I think the 'better' solution, as discussed in email, is a different API that uses Scala native types rather than SiriusResult, at least for future clients.

clinedome-work commented 10 years ago

Hmm, if we did this, wouldn't the method signature of anything in Java that calls getValue() have to change? I imagined that would get inferred through, but I'm not entirely sure.

Whether SiriusResult is the right answer or not, I'd say there's value in avoiding the nested Scala-native types, even if they do most succinctly describe what's happening. They're a total bear to work with in Java.

All for looking at this stuff in more detail for 1.2 though.

smuir commented 10 years ago

Interesting question. I don't think the signature of getValue() is changed by changing the underlying type of the exception field.

clinedome-work commented 10 years ago

Upon testing, it doesn't. :)

smuir commented 10 years ago

Updated to add an exception() method to wrap Throwable, with error() being reverted to the original interface of accepting only a RuntimeException

smuir commented 10 years ago

Just made a minor to change to make it possible to directly retrieve the Throwable associated with a SiriusResult.

smuir commented 10 years ago

The Travis CI build sometimes seems to fail for one of the two versions of Scala compiler, but not the other. Anyone got any ideas why?

comcast-jonm commented 10 years ago

This might need rebasing and resubmitting now that we're on a public TravisCI build.

smuir commented 10 years ago

If we are going to consider a new 1.3 release that has a more standard return type than SiriusResult, a la #26, then this might not be worth bothering with. But it seems like #26 was generally decided against, in which case this could easily be respun if it was thought to be useful. It probably isn't actually useful until we get to the point that return values actually propagate from the RequestHandler (issue #6 )

CLAassistant commented 5 years ago

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.