Read into sealed traits and case classes in Scala. The short version is: -- A sealed trait means that all of the subclasses have to be defined in the same file. -- These are often implemented as case classes that define all the possible subclasses you can have. -- If you match on a sealed trait, the compiler will warn you if it has subclasses that you aren't testing for.
This lets you make sure that your Actor is actually handling all the messages it is supposed to. It does *not* protect you from external systems sending messages that aren't subclasses of that trait, but that's a relatively rare error in my experience. (You could theoretically protect *somewhat* against it by defining a wrapper function around tell in your companion object, that only accepts the appropriate message types, but I've never found that worth the hassle...) On Fri, Jan 3, 2014 at 9:23 AM, Maatary Okouya <[email protected]>wrote: > I found this in the fact, but i'm not sure to understand the exhaustive > part: > > How can I get compile time errors for missing messages in receive? > > One solution to help you get a compile time warning for not handling a > message that you should be handling is to define your actors input and > output messages implementing base traits, and then do a match that the will > be checked for exhaustiveness. > > Here is an example where the compiler will warn you that the match in > receive isn't exhaustive: > > > 1. object MyActor { > 2. // these are the messages we accept > 3. sealed abstract trait Message > 4. case class FooMessage(foo: String) extends Message > 5. case class BarMessage(bar: Int) extends Message > 6. > 7. // these are the replies we send > 8. sealed abstract trait Reply > 9. case class BazMessage(foo: String) extends Reply > 10. } > 11. > 12. class MyActor extends Actor { > 13. import MyActor._ > 14. def receive = { > 15. case message: Message => message match { > 16. case BarMessage(bar) => sender ! BazMessage("Got " + bar) > 17. } > 18. } > 19. } > > > Could you help and explain, why the compiler will make a warning ? > > On Friday, January 3, 2014 11:25:29 AM UTC+1, rkuhn wrote: > >> Hi Maatary, >> >> if you look at the Akka documentation or browse for blog posts you'll see >> that usually the message types accepted and emitted by an actor are >> declared together with it--in the same package or in its companion object. >> These messages are a perfect match for case classes since they need to be >> immutable and should have appropriate deconstructors for pattern matching: >> >> object MyActor { >> sealed trait Command >> case class DoIt(name: String, id: Int) extends Command >> ... // further commands >> >> sealed trait Reply >> case object Done extends Reply >> } >> >> class MyActor extends Actor { >> def receive = { >> case DoIt(name, id) => >> // do it >> sender ! Done >> ... // further cases >> } >> } >> >> Regards, >> >> Roland >> >> 2 jan 2014 kl. 03:22 skrev Maatary Okouya <[email protected]>: >> >> Hi, >> >> I just start trying myself out with Scala. I grow confident enough to >> start refactoring an ongoing multi-threaded application that i have been >> working on for about a year and half. >> >> However something that somehow bother and i can't somehow figure it out, >> is how to expose the interface/contract/protocole of an Actor? In the OO >> mode, i have my public interface with synchronized method if necessary, and >> i know what i can do with that object. Now that i'm going to use actor, it >> seems that all of that won't be available anymore. >> >> More specifically, I a KbService in my app with a set of method to work >> with that Kb. I want to make it an actor on its own. For that i need to >> make all the method private or protected given that now they will be only >> called by my received method. Hence the to expose the set of available >> behavior. >> >> Is there some best practice for that ? >> >> -- >> >>>>>>>>>> Read the docs: http://akka.io/docs/ >> >>>>>>>>>> Check the FAQ: http://akka.io/faq/ >> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user >> --- >> You received this message because you are subscribed to the Google Groups >> "Akka User List" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> >> Visit this group at http://groups.google.com/group/akka-user. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> >> >> *Dr. Roland Kuhn* >> *Akka Tech Lead* >> Typesafe <http://typesafe.com/> - Reactive apps on the JVM. >> twitter: @rolandkuhn >> <http://twitter.com/#!/rolandkuhn> >> >> -- > >>>>>>>>>> Read the docs: http://akka.io/docs/ > >>>>>>>>>> Check the FAQ: http://akka.io/faq/ > >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user > --- > You received this message because you are subscribed to the Google Groups > "Akka User List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/groups/opt_out. > -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: http://akka.io/faq/ >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/groups/opt_out.
