Designing Scala library which wraps a Java library

Question

I'm designing a simple scala wrapper library over a java library in order to make it more idiomatic scala. The problem I faced with is that all operations from the java library could throw an exception, which is RuntimeException, but very similar to IOException. So I'm wondering if it's a good idea to wrap all of them into Either or I should leave it to a user of my library? I guess I should leave it to a user, but I'd like to make sure, that I'm right.

• gnat: Why use Either over (checked) Exception?
• alex: @gnat In fact, it's a successor of RuntimeException, but by its meaning it's very similar IOException.
• Brian Smith: Do you have to choose between exceptions, Either, or other suggestions (Try / Future)? Could you offer the user the choice without the API becoming too cluttered?
• alex: For now, I'm considering Future, because asynchrony is a good bonus in my case.

Answer 1

If the occurrence is very rare, I would let it propagate. If it is relatively common, I would actually prefer a Future. They are already designed to contain exceptions, and many tasks that fail frequently also tend to benefit from asynchronous execution, like network IO and database queries. It's quite common to see APIs full of functions that return Futures, whereas I've never seen one that makes heavy use of Eithers.

Answer 2

Depends on your target audience. If you're aiming for the more FP side of the Scala community, exceptions for anything but critical failures are unacceptable - they make for unsafe code. I'd wrap errors in an Either, or at the very least a Try. Preferably an Either, since they don't hardwire failure onto exceptions and are properly right biased in recent versions.

If you're aiming for the more intermediate / OOP side of the Scala community, exceptions are fine, that's what's usually expected.