Before mentioning any sse-breaker specifics lets quickly define what is a Circuit Breaker. A Circuit Breaker is a software component that keeps track of the error rate of various operations and when the rate is high it prevents those operation from executing by failing-fast.

In sse-breaker the Circuit Breaker is implemented as an executor. To use it you create a CircuitExecutor instance and call its apply[T](op: =>T):T method passing the code that you would like to execute in the closure. Depending on the Circuit Breaker’s state (if errors have occurred recently) the executor will execute the requested operation or it will throw an OpenCircuitException.

For example lets say that we are developing a web application that uses the Twitter API. Obviously we wouldn’t want any capacity problems at Twitter (or any other site) to prevent our pages from rendering fast. To protect our application we could wrap any calls to the Twitter API with a Circuit Breaker.

To do this in sse-breaker we could use the following code:

class TwitterGateway(twitter: Twitter) {

  private val failfast = new CircuitExecutor("twitter-breaker")

  def getTimeline: List[Status] = failfast {
    twitter.getFriendsTimeline
  }

  def search(q: Query): QueryResult = failfast {
    twitter.search(q)
  }
}

In the above code we’ve created a CircuitExecutor, named twitter-breaker, with the default configuration and wrapped the calls to the Twitter API. By default if five exceptions are thrown within a minute the Circuit Breaker will go into the open state and further requests to execute any operation, for the next 10 minutes, will throw an OpenCircuitException instead of executing the operation.

For more information see the homepage of sse-breaker.

try {
  iMayHaveIllegalState.doSomething()
} catch {
  case e: IllegalStateException => e.printStackTrace()
}

we can simply write:

try {
  iMayHaveIllegalState.doSomething()
} catch {
  case e => e.printStackTrace()
}

You might be tempted to use the above code in your programs since it is shorter but if catching Throwable in Java is evil then catching Throwable in Scala is ten times more evil.

To illustrate this we will use a small example. Lets say that we want to write a method that takes a sequence of strings and tries to find if it contains a string that represents an even number. Furthermore if any of the strings cannot get converted into an integer then we assume that the input is invalid and return false.

A possible implementation is the following:

def containsEven(nums: String*): Boolean = {
  try {
    for (i <- nums) {
      if (i.toInt % 2 == 0)
        return true
    }
  } catch { case e => () }
  false
}

From the above implementation we would expect that containsEven("1", "3") should return false and that containsEven("2", "3") should return true. Unfortunately this is not the case and regardless of the input our method always returns false. This is because in the catch block we used a pattern that catches Throwable with the expression case e => ... instead of the longer but more correct pattern case e: NumberFormatException => ... that only catches NumberFormatException. To understand why this is the cause of the bug we need to understand how Scala implements non-local return from closures.

The for loop in the above code is actually a method call to the the foreach method of the nums object (that is an instance of scala.Seq) passing the body of the for loop as a closure in the foreach method. The code inside the for loop is actually the apply(..) method of the closure (a scala.Function1 in our case). Since that code belongs in another method normally a return statement present in that code would signal the return of that method.

This is not the case for Scala’s closures and when a return statement is present in a closure, the closure instead of returning at the point of invocation it also triggers the return of the enclosing method. This behavior is called non-local return and it is essential for creating control-flow abstractions using closures.

Because the JVM does not have native support for non-local return Scala implements it by throwing a Throwable. When a closure contains a return statement then that closure when executed instead of returning normally it throws a Throwable of type scala.runtime.NonLocalReturnControl that contains the returned value of the closure. The NonLocalReturnControl is then caught at the enclosing method and closure’s returned value is returned from the enclosing method. This is why when we try to define a closure that contains a return statement outside of a method the compiler will complain with an error because it cannot find where to generate the catch block for the NonLocalReturnControl thrown from the closure.

With the knowledge of how non-local return is implemented in Scala, we can now see that in the containsEven method the NonLocalReturnControl that gets thrown from the return true statement in the for loop gets caught by our case e => () pattern and gets ignored. So regardless of the input containsEven will always return false. To fix this we must simply catch NumberFormatException and not Throwable.

def containsEven(nums: String*): Boolean = {
  try {
    for (i <- nums) {
      if (i.toInt % 2 == 0)
        return true
    }
  } catch { case e: NumberFormatException => () }
  false
}

Catching Throwable can be a source of frequent bugs because even with the knowledge of how non-local return is implemented it is very likely that you will miss a closure with non-local return and introduce a bug. Furthermore Scala implements and other control structures by throwing Throwable like break and continuations making it even harder.

In the rare case when you absolutely need to catch Throwable the correct way to do it is the following:

import scala.util.control.ControlThrowable

try {
  codeThatMayThrowThrowable()
} catch {
  case e: ControlThrowable => throw e
  case e => handleThrowable(e)
}

In the above code we re-throw a Throwable if it is used for control-flow and handle all others. The scala.util.control.ControlThrowable is the Throwable that is extended by all throwables that are used for control flow in Scala.

One of Scala’s unique features is singleton objects. Singleton objects are an implementation of the Singleton design pattern inside the language and they allow Scala to abandon static methods and provide a more uniform view of the world where everything is an object.

Singleton objects despite all their benefits they make one bad practice very convenient to do. It is very easy to forget that an object (that is not defined inside a class or trait) is actually a global static and thus a var inside that object is actually global mutable state.

This is not a Scala weakness and I believe it is more a weakness of the programmer to come up with the right design given his unfamiliarity with the Scala constructs. When we start using a new programming language because we are re-evaluating our view of programming certain bad practices that we might never used in our previous language temporarily become more tempting.

One example of global mutable state in a top-level singleton object that I saw recently is in Squeryl. Squeryl is an ORM that has a really slick API and IMHO could become a viable alternative to the major Java ORMs for Scala.

I was reading Squeryl’s documentation and I got really excited about using it in a small project but then I saw the SessionFactory object and my excitement turned into disappointment. Below I have a small fragment from the SessionFactory‘s code:

object SessionFactory {

  var concreteFactory: Option[()=>Session] = None

  var externalTransactionManagementAdapter: Option[()=>Session] = None

  def newSession: Session = {
    /* Code that uses concreteFactory... */
  }
}

As you can see from the above code the SessionFactory has two vars that hold functions that create ORM sessions. I have to say that I am at least uncomfortable with an ORM that relies on global mutable state for that functionality.

Lets try to enumerate some of the disadvantages of Squeryl’s current design:

1. Since the concreteFactory and externalTransactionManagementAdapter can be changed from anywhere in the program it is difficult to reason about our code.
2. The API of SessionFactory is not thread-safe. For example if a thread changes concreteFactory then another thread reading that variable does not have a guarantee that will see the latest version.
3. Since the configuration for creating a Session is in a static variable this means that we cannot have a multi-threaded application that uses two different configurations.
4. As a consequence of the above we cannot deploy Squeryl as an OSGi bundle and use it from multiple applications.
5. Since we depend on global state, our code is more difficult to test because we need to reset that state after every test.
6. Furthermore we cannot run our tests in parallel.

Lots of bad stuff for two innocent vars…

Update: Maxime Lévesque, the author of Squeryl, wrote in a comment that Squeryl also provides a mechanism for working with sessions that does not rely on static state and that the mechanism described in this article is optional and provided for convenience. So my analysis above is not true and would only be valid if Squeryl didn’t provide an alternative mechanism.

In conclusion:

• Putting a var inside an object might be convenient but as each instance of global mutable state it can lead to a lot of trouble.
• Just because you moved to a new programming language doesn’t mean that your old practices are now unnecessary.

Below we have a small Guice module (copied from the documentation of AbstractModule) defined in Java.

public class MyModule extends AbstractModule {
  protected void configure() {
    bind(Service.class).to(ServiceImpl.class).in(Singleton.class);
    bind(CreditCardPaymentService.class);
    bind(PaymentService.class).to(CreditCardPaymentService.class);
    bindConstant().annotatedWith(Names.named("port")).to(8080);
  }
}

In Scala the above code would be:

class MyModule extends AbstractModule {
   protected def configure() {
     bind(classOf[Service]).to(classOf[ServiceImpl]).in(classOf[Singleton])
     bind(classOf[CreditCardPaymentService])
     bind(classOf[PaymentService]).to(classOf[CreditCardPaymentService])
     bindConstant().annotatedWith(Names.named("port")).to(8080)
   }
 }

As you can see the code is longer and it looses the DSL feel that it has in the Java version. This fact may lead Scala developers away from Guice since defining Guice modules in Scala feels awkward and leaves a lot to be desired.

For this reason I’ve created a small project, called sse-guice, that extends Guice’s internal DSL with methods that make defining Guice modules in Scala more pleasant.

What I’ve done is to extend the binder interfaces of Guice (defined in com.google.inject.binder package) and add a method that takes a Manifest for each method that takes a Class as a parameter. Furthermore I’ve extended the AbstractModule class (the entry point of the Guice internal DSL) and added a bind method that accepts a Manifest and I’ve also overridden all the methods that return a binder interface to return the extended binder interfaces provided by sse-guice.

By utilizing sse-guice the above module can be rewritten as:

class MyModule extends ScalaModule {
  protected def configure() {
    bind[Service].to[ServiceImpl].in[Singleton]
    bind[CreditCardPaymentService]
    bind[PaymentService].to[CreditCardPaymentService]
    bindConstant().annotatedWithName("port").to(8080)
  }
}

As you can see the code now is shorter, easier to read and feels like a proper internal DSL.

Another benefit of using Manifest as a parameter is that we can now avoid creating TypeLiterals when we bind generic types. To bind a generic type in Guice you have to write:

bind(new TypeLiteral[Validator[Registration]] {}).to(classOf[RegistrationVSpec])

but when using sse-guice we can simply write:

bind[Validator[Registration]].to[RegistrationVSpec]

because Manifest also holds any type arguments and sse-guice automatically creates a TypeLiteral when the Manifest contains type arguments.

I am coding a small JMX library in Scala, similar to Spring’s JMX module and to the jmxutils library. In my project I have a MBeanInfoAssembler trait, that is a strategy interface, whose role is to create a ModelMBeanInfo from a Class. Implementations of that trait will use reflection to discover the attributes and operations that will be used to export instances of the Class to JMX.

trait MBeanInfoAssembler {
  def createMBeanInfo(clazz: Class[_]): ModelMBeanInfo
}

The first implementation of the trait was the SimpleMBeanInfoAssembler class which uses reflection and some conventions to discover the attributes and operations.

class SimpleMBeanInfoAssembler extends MBeanInfoAssembler {

  def createMBeanInfo(clazz: Class[_]): ModelMBeanInfo =
    new ModelMBeanInfoSupport(clazz.getName,
                              clazz.getSimpleName,
                              attributes(clazz),
                              Array(),
                              operations(clazz),
                              Array())

  private def attributes(c: Class[_]): Array[ModelMBeanAttributeInfo] = {
    //find the attributes from the class using reflection
  }

  private def operations(c: Class[_]): Array[ModelMBeanOperationInfo] = {
    //find the operations from the class using reflection
  }
}

In the above code I have removed the implementations of the attributes and operations methods because they are not important for this example. What is important is the createMBeanInfo method which just calls the ModelMBeanInfoSupport constructor with the results of the attributes and operations methods. If we leave the code like this, when we try to provide a second implementation of the MBeanInfoAssembler trait we will probably copy-paste that method’s code.

In Scala, traits can have concrete methods so our first though is to move the implementation of the createMBeanInfo method to the MBeanInfoAssembler trait. After doing that our trait becomes:

trait MBeanInfoAssembler {
  def createMBeanInfo(clazz: Class[_]): ModelMBeanInfo =
    new ModelMBeanInfoSupport(clazz.getName,
                              clazz.getSimpleName,
                              attributes(clazz),
                              Array(),
                              operations(clazz),
                              Array())

  def attributes(c: Class[_]): Array[ModelMBeanAttributeInfo]

  def operations(c: Class[_]): Array[ModelMBeanOperationInfo]
}

and the implementation:

class SimpleMBeanInfoAssembler extends MBeanInfoAssembler {

  def attributes(c: Class[_]): Array[ModelMBeanAttributeInfo] = {
    //find the attributes from the class using reflection
  }

  def operations(c: Class[_]): Array[ModelMBeanOperationInfo] = {
    //find the operations from the class using reflection
  }
}

This refactoring has the obvious advantage of removing the repetition that would be needed to create multiple implementations of MBeanInfoAssembler but also one major disadvantage over our previous code.

In order to support the implementation of the createMBeanInfo method the MBeanInfoAssembler trait gets updated with two new public abstract methods (attributes and operations). Those methods are useless to the clients of the trait, who only want to create a ModelMBeanInfo from a Class, and are there only to support the trait’s implementation. To correct this defect in our design we need to do another refactoring by introducing a new trait and connecting the two traits together using a self type annotation.

If you are new to Scala you might wonder what is a self type? In the Scala documentation self types are described as a way to “declare the type of the value this explicitly” which might be accurate but sounds at least confusing for a newbie like me.

In a well designed object-oriented system we achive reuse and flexibility when our system has lots of small objects that have a single responsibility and are explicitely connected using interfaces that represent the role of the connection. Usually those connections are made using constructor arguments. The power of such system comes from the testability and reusability of the small objects and the flexibility of composing those objects to solve a particular problem.

Since traits in Scala can have code (method implementations), if we want to create an equally well designed and flexible system using traits we need to be able to do the same. The problem is that traits do not have constructors so we need a new construct to declare trait dependencies and also a way to compose traits together. The solution to the first problem are the self type annotations and the solution to the second is multiple inheritance.

In the previous example the MBeanInfoAssembler trait had many responsibilities assigned to it. It must be able to create a ModelMBeanInfo given a Class and it must also extract any metadata in order to find the right attributes and operations for the given Class. We decide to move the second responsibility to a new trait called MBeanMetadataExtractor that has the attributes and operations methods.

trait MBeanMetadataExtractor {

  def attributes(c: Class[_]): Array[ModelMBeanAttributeInfo]

  def operations(c: Class[_]): Array[ModelMBeanOperationInfo]
}

Now we need to update the MBeanInfoAssembler trait and to somehow connect it to the MBeanMetadataExtractor trait so it can use the attributes and operations methods. To do this we will use a self type annotation.

trait MBeanInfoAssembler {

  this: MBeanMetadataExtractor =>

  def createMBeanInfo(clazz: Class[_]): ModelMBeanInfo = {
    new ModelMBeanInfoSupport(clazz.getName,
                              clazz.getSimpleName,
                              attributes(clazz),
                              Array(),
                              operations(clazz),
                              Array())
  }
}

The syntax of the self type annotation is this: MBeanMetadataExtractor => and it tells the compiler that a MBeanInfoAssembler can be implemented in a class only if that class also implements the MBeanMetadataExtractor trait. Using this assumption the compiler makes the methods of the MBeanMetadataExtractor available for use in the MBeanInfoAssembler (in our case the attributes and operations methods).

The class SimpleMBeanInfoAssembler now has to implement both MBeanInfoAssembler and MBeanMetadataExtractor.

class SimpleMBeanInfoAssembler extends MBeanInfoAssembler with MBeanMetadataExtractor {

  def attributes(c: Class[_]): Array[ModelMBeanAttributeInfo] = {
    //find the attributes from the class using reflection
  }

  def operations(c: Class[_]): Array[ModelMBeanOperationInfo] = {
    //find the operations from the class using reflection
  }
}

By doing the above changes we were able to hide the attributes and operations methods from the clients of the MBeanInfoAssembler trait. Obviously those methods exist in the public interface of SimpleMBeanInfoAssembler but in a well designed system other classes will connect with SimpleMBeanInfoAssembler by using one of its traits (interfaces) so this is not a problem.

In conclusion, if we want to move method implementations inside traits then we risk polluting the interface of those traits with abstract methods that support the implementation of the concrete methods and are unrelated with the main responsibility of the trait. A solution to this problem is to move those abstract methods in other traits and compose the traits together using self type annotations and multiple inheritance.