This page is no longer maintained — Please continue to the home page at

Inconvenient representation of actor's exit reasons when using linking

No replies
Nikolay Artamonov
Joined: 2010-09-08,
User offline. Last seen 42 years 45 weeks ago.

I have some actor-based code that uses actor's ability to linking each
other with Last day I spent trying to find out what
possible reasons can produce actor when dies. By "reason" I mean
second parameter in scala.actors.Exit(_, reason) which has type

I must admit: it was terrible experience. Right now, after writing
some small pieces of code to test actors' behaviour in presence of
linking and after digging into actors' source code, I find out two
possible reasons: symbol 'normal and wrapper UncaughtException. And
still I don't have any confidence that somewhere deep in actor's
internals there are no other class used for signaling reasons. I feel
like I come back to old days when I use dynamic languages for my work.
No documentation about possible values of parameters, representation
of similar concepts by totally unrelated types, necessity to dig deep
into internals of libraries.

I really, really don't understand: are there some *good objective
technical reasons* to use dynamic typing in modern statically typed
language with higher-kinded polymorphism, type classes, MOST advanced
(and type-safe!) collection library, and bunch of other mind-blowing
features? Why we can't reduce actor's exit reasons to class hierarchy?
Something like:

trait Reason
case object Normal extends Reason
case class UncaughtException(e: Throwable) extends Reason
case class UserSpecifiedReason(r: AnyRef) extends Reason

This code also *is* good documentation. Doctool will make work for us,
tracing interrelations between types in hierarchy. We really haven't
dig into actors' source code to begin use actors' linking feature.
Currently we have totally unrelated types and NO documentation and NO
help from doctool.

Btw, what other exit reasons exist apart from 'normal and
UncaughtException? Thanks.

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland