Scala Futures and Stack Traces

I’ve been digging into a real Scala codebase for a while now and I’ve been enjoying a lot of it. The trait system in practice works way better than it looks like it would, mostly since all the pre-research I’d done involved people talking about the difficult bits because the normal use cases work out easily (and are therefore uninteresting). The integration with tools and libraries worked out great in most ways; however, the error message you get when a Java class and a Scala class have conflicting names wasn’t ideal even if it worked. The import rename syntax (ex. import scala.collection.mutable.{Map => MMap}) fixed the problem easily enough.

The big gripe I’ve had so far is with debugging future-based programs. The big issue is that when an exception gets thrown in a future, the stack trace doesn’t give any idea of what scheduled the future. The problem has been recognized as a Scala bug, but it doesn’t seem to be getting dealt with since it was opened in 2014 and hasn’t been updated since 2015. This is also partly a tooling issue since the step in functionality doesn’t work the way you’d want it to. Stepping into a method that returns a future doesn’t actually step in. It just schedules that action to occur, it doesn’t actually happen yet and will happen on another thread when it does.

A possible solution would be if the step-in action in the debugger put a breakpoint inside the method being scheduled with some sort of conditional. Not sure what the downside would be to this particular solution. I don’t see a reasonable way to add this as a plugin or a script in some other way. Forking IntelliJ itself doesn’t seem like a good idea either since that’s the community edition, and that doesn’t support all of the plugins we are using plus all of the ongoing support issues with that.

The one gripe against the stack doesn’t out weigh all of the positive aspects. The concise syntax is great. While I haven’t had any opportunity to really dig into the performance aspects of working with futures yet, I expect they will hold up as expected. The type system is expressive and safe. Higher order functions aren’t as much of a differentiating factor over Java with lambdas in Java 8 but they aren’t integrated into the libraries the way they were in C# or are in Scala. Overall, I’m excited with my choice and will keep digging in.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s