Thanks @pwendell, the easiest thing could be to avoid a longer discussion and just use the `try-catch` block but I do think that the `Try` monad is a good option. It won't swallow _fatal_ errors based on [NonFatal](https://github.com/scala/scala/blob/v2.10.3/src/library/scala/util/control/NonFatal.scala#L1) and can handle specific error recovery scenarios through `recoverWith`. What it avoids is cases where you return `null`, which overall is not a good practice, and the _bubbling_, mostly by mistake, of errors that should not disable a program/application while enabling _functional composition_.

In the end, I will align with the view of the **Apache Spark Project**. Let me know and I'll make the changes without further arguments, but if we decide to use the `try-catch` block please let me know how `populateHadoopClasspath` should handle the exception:
1. _bubbling_ it up in case it is not either a `NoSuchFieldError` or a `NoSuchFieldException`.
2. ignore every type, and potentially just log warnings.
Plus handling of the returned value.
1. null = empty 
2. don't even assume that `null` will be returned and treat it as the original implementation did.