Return to Answer

• 1

• 491
• 4
• 12

A number of smaller issues stand out:

• you don't actually use final private String sep; anywhere. this variable can be removed. (you use _sep only inside the constructor)

• There doesn't seem to be a clear need to use a lambda expression to set the filestream variable. You actually introduce an extra type (Supplier<...>) to be able to use lambda.

• You don't actually handle the exceptional situation inside the lambda:

What if fileStream ends up being null ?

fileStream = () -> {
 try {
 return Files.lines(Paths.get(filename), Charset.defaultCharset());
 } catch (IOException e) {
 e.printStackTrace();
 return null;
 }
 };

Then you use it later on:

List<String[]> colsList = fileStream.get()

I can see a use for lambda expressions in general if they are an argument to a method (so a method can more easily be reused with different actions, like iteration or other circumstances.)

However the benefit in using them in this occasion evades me:

fileStream = () -> {
 try {
 return Files.lines(Paths.get(filename), Charset.defaultCharset());
 } catch (IOException e) {
 e.printStackTrace();
 return null;
 }
 };

versus

try {
 fileStream = Files.lines(Paths.get(filename), Charset.defaultCharset());
} catch (IOException e) {
 e.printStackTrace();
}

Perhaps you or another reviewer can point out to me what the benefit is of using lambda in this situation. I just see more room for errors.

The additional problem is in my opinion: what if you want to throw a checked exception when you catch an IOException? As far as I know you cannot throw a checked exception from inside a lambda block that doesn't throw it. (see this question)

So what if somewhere down the line you want to throw this exception or a similar one? You would either have to rewrite it to not use lambda expressions, or throw an unchecked exception, catch and rethrow as checked.

To me this seems really wrong. Lamdba is very good for specific purposes but not for convenience methods. Try to keep them simple and to the point and make the chance that anyone will want to throw an exception to a minimum. Or handle the actual exception

When you write this the first time, none of this will be an issue but during the maintenance lifecycle this will eventually cause someone to swear. anyways this is 2 months after I decided against raging against lambda's :D they're not bad but I don't recommend using them for the sake of using lambda's.

• Agree with @JvR, don't force encodings onto users. It's better to have them individually chosen. Having said that, why anyone would use non-utf-8 is beyond me.

anyways no further time I may come back and put more in. but since you asked I added my anti-lambda bit in there, including the exception part as best as I remembered it at the time