1

So, very often in your code you have statements/algorithms like this one:

if (!myCollection.contains(unit))
  throw new IllegalArgumentException(s"$unit is not available")

The issue which I have with this approach that it clutters you source-code - this is especially true if you need extensive checks.

I was thinking if such repetitive algorithms, checks etc. are more elegant solvable in scala, e.g. by a DSL ?

  • 1
    This question's a bit unclear, but I've resolved this exact type of behaviour numerous times using functional approaches you can find in the Maybe or Either monad... Though more often than not it's not worth it, you have to be in a large boiler-plate heavy bit of code to make it worth the abstractions confusion most developers will experience upon looking at an eDSL (seriously, most devs have no idea what an eDSL is and will not be pleased with such foreign stuff in their code base). eDSLs will significantly reduce boiler plate though so if you have tons of repetitive stuff like that.. – Jimmy Hoffa Oct 23 '15 at 14:08
  • 1
    Just use require from the standard library - daily-scala.blogspot.co.il/2010/03/assert-require-assume.html – Idan Arye Oct 23 '15 at 15:27
3

While you can use certain abstractions like a DSL to simplify things like argument checking, in functional programming, that sort of error handling by side effect is usually avoided altogether by the way you structure your program.

For example, an availability check might look something like this:

def firstAvailableUnit(): Option[Unit] = {
  val available = units filter {_.available == true }
                        filter {_.occupancy == 4 }
                        filter {_.haunted   == false }

  available.headOption
}

// The calling code:
println(firstAvailableUnit() map {_.name} getOrElse "No units available")

OOP uses a sort of blunt-instrument approach to validation. Once you get the hang of the idiomatic FP way, it feels a little like your arguments are almost already magically validated for you.

  • Thanks for your input. The functional validations look indeed nicer, especially if you have a couple of validations. Concerning the option in Scala: I would not use it in general as a replacement of exceptions, since the latter one has additional qualities like propagation. I consider 'Option' as a means to indicate that returning a 'null' value is valid, whereas an exception shall indicate that you have an erroneous state in your application. Any thoughts on this ? – Marco Oct 24 '15 at 6:51
  • 1
    Exceptions are very rare in functional programming, because propagation up the stack is a very limited form of control flow. It only goes one way and it's hard to predict where your stack will be in FP. Options, Eithers, Futures, and your own similar control flows built from first-class functions give you much more finer grained control flow that helps keep you from getting into "erroneous states" in the first place. – Karl Bielefeldt Oct 24 '15 at 14:39
  • 1
    You can assign them to variables, pass them all over the place, to functions in any direction. You can copy them and reuse them to avoid duplication. They are much more useful than exceptions, once you stop thinking of them as "null replacements." – Karl Bielefeldt Oct 24 '15 at 14:39
  • I see your point Karl. I think it depends on the solution/app, which you are building. I have an OO/FPmix-style, since I write the UI also in Scala and here OO has its advantages, too. But thanks to your input I've checked my source code and started to make much more use of 'Option/FP' approach concerning validation and god rid of several instances where I've used exceptions :) – Marco Oct 25 '15 at 10:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.