When you first start reading files in Scala, you'll likely reach for scala.io.Source. It's the standard library's "quick and dirty" way to get data off the disk. But there is a trap here that almost every developer falls into during their first few tries.

The "getLines() is a List" Misconception

The most common mistake I see is assuming that Source.fromFile("...").getLines() returns a List or some other persistent collection. It looks like one, it acts like one when you call foreach or filter, but it isn't. It's an Iterator.

Let's look at a concrete example. Imagine you're writing a small tool to analyze a users.txt file where each line is a username. You might try something like this:

val source = scala.io.Source.fromFile("users.txt")
val lines = source.getLines()

println(s"Total users: ${lines.size}") 
println("User list:")
lines.foreach(println) 
// Result: Total users: 10, but the User list is empty!

You'll see the count, but the foreach loop will do absolutely nothing. Why? Because an Iterator is a one-way street. Once lines.size traverses the file to count the elements, the pointer is at the end of the file. There is no "rewinding." The data is gone from the iterator's perspective.

Treating the Source as a Lazy Stream

To fix this, you have to decide if you want the data in memory or if you want to process it on the fly. If the file is small enough, the easiest fix is to call .toList immediately. This "realizes" the iterator into a concrete collection that you can traverse as many times as you want.

val source = scala.io.Source.fromFile("users.txt")
val lines = source.getLines().toList // Now it's a List[String]
source.close() // Don't forget this!

println(s"Total users: ${lines.size}")
lines.foreach(println) // This works now

Now, here is a bit of professional advice: scala.io.Source doesn't magically close the file handle when you're done with the iterator. If you're reading a few files in a script, it doesn't matter. But if you're doing this inside a long-running server application, you'll eventually hit a "Too many open files" OS error. Always call .close() on the source object.

If the file is massive—say, a 2GB log file—you definitely shouldn't use .toList because you'll crash your JVM with an OutOfMemoryError. In those cases, you embrace the Iterator. You perform all your transformations (filter, map) and your final "terminal" operation (like sum or foreach) in one single chain. This way, Scala reads the file line-by-line without ever loading the whole thing into RAM.

Here is how I typically handle a large file to keep it memory-efficient:

val source = scala.io.Source.fromFile("large_logs.txt")
try {
  val errorCount = source.getLines()
    .filter(_.contains("ERROR"))
    .map(_.trim)
    .size
  println(s"Found $errorCount errors.")
} finally {
  source.close()
}

I wrapped that in a try/finally block because if an exception occurs while processing the lines, I still want that file handle closed. It's a habit that will save you from some very annoying production bugs.

📋 Practical Task

Parsing a Server Log for Error Counts

You have a file named server.log containing various log entries. Some are INFO, some are WARN, and some are ERROR.

Write a Scala program that does the following:

• Opens server.log using scala.io.Source.
• Filters the lines to keep only those that start with the word "ERROR".
• Transforms those lines to remove the "ERROR: " prefix (so you only have the error message itself).
• Collects these messages into a List.
• Prints the final list of error messages and the total count of errors found.
• Ensures the source is closed properly, even if an error occurs.

Note: For the sake of the exercise, you can assume the file exists and follows the format: ERROR: Database connection failed