Take the 2-minute tour ×

How can I archive a kind of Option type which either returns something of type T or of type Error?

I am doing some web requests and the responses are either "ok" and contain the object or the call returns an error, in which case I want to provide an Error object with the reason of error.

So something like:

def myRequest() : Result[MyObject] {
  if (thereWasAnError) Error(reason) else MyObject 
share|improve this question
By the way, this kind of thing is better handled by Scalaz Validation. –  Daniel C. Sobral May 28 '12 at 15:53
Can you provide a link with an example? What is the advantage? It would be an additional dependency... –  user3001 May 28 '12 at 18:18
Look it up -- both on Stack Overflow and outside it. It's difficult to explain the advantages, beyond it just being a better abstraction than Either. For that matter, Lift also has an alternative -- Box -- also a result of Either inadequacies. –  Daniel C. Sobral May 28 '12 at 20:57
Daniel is right, Validation is definitely better. The simple reason being that Validation is right biased and that you can more easily accumulate errors on the left by having a SemiGroup (reducer function basically) for the left/error type. See the following for an excellent intro: github.com/mpilquist/scalaz-talk –  Jed Wesley-Smith May 28 '12 at 22:35
Thanks :) I am writing a scala library with that particular problem. I first decided that Exceptions are no choice, as an Error from the web service is a result which can happen. Exceptions are not checked. If you would be using a library for a web service, you would prefer Validation, although there is only one type of Error, right? –  user3001 May 28 '12 at 22:40
add comment

1 Answer

up vote 10 down vote accepted


Either type should be exactly what you want:

def myRequest() : Either[String, MyObject] = 
    if (thereWasAnError) 
        Left("Some error message") 
        Right(new MyObject)

Either is similar to Option but can hold one out of two possible values: left or right. By convention right is OK while left is an error.

You can now do some fancy pattern matching:

myRequest() match {
    case Right(myObject) =>
    case Left(errorMsg) =>


Similarily you can use Option and translate it to Either. Since typically *right* values is used for success and left for failure, I suggest usingtoRight()rather thantoLeft()`:

def myRequest() : Option[MyObject] =
    if (thereWasAnError)
        Some(new MyObject)

val result: Either[String, MyObject] = myRequest() toRight "Some error message"

However returning Either directly as a result of myRequest() seems more straightforward in this simple example.

share|improve this answer
Which is the better way? Either or case classes, like aioobe suggests? I guess in both cases I have to unwrap the object in the "OK" case to get the MyObject result? –  user3001 May 28 '12 at 13:11
@user3001: Either was specifically designed for cases like yours (two types of results, where one is considered an error or failure object). case classes as aioobe suggested are much more powerful as you can have more than two options (unlikely in your situation). Also Either is built-in. Both solutions can use pattern matching to extract values easily (see my second code snippet and Either documentation). –  Tomasz Nurkiewicz May 28 '12 at 13:20
I discovered that the Option type has the mehtods {{toLeft}} and {{toRight}} which are really useful. Is there any community standard which of the two arguments should be the Error object? –  user3001 May 28 '12 at 13:57
@user3001: see my update –  Tomasz Nurkiewicz May 28 '12 at 14:04
What I did was to use toRight to have a shorthand function: def result[T]( xmlConverter :(NodeSeq) => T) : Either[T, Error] = error.toRight(xmlConverter(xml)) So if there was an error, return an Error object, else create a resulting object from the xml –  user3001 May 28 '12 at 14:23
add comment

Your Answer


