1

I have a scenario in which I want to abort the entire progress if any of the iterated objects have some certain bad condition (not valid or whatever). I don't want to just skip this specific object and go on with the rest.

As an example take reading a CSV file. If one of the lines have less/more elements than the header line, I will have problems mapping it. I then want to abort the process with an exception "csv file is invalid" which I catch in higher level to react properly.

I use something like this:

csvLines.forEach(line -> {
    if (line.isValid()) {
        doSomethingWith(line);
    } else {
        // ABORT MISSION, I REPEAT, ABORT!
        // throw new CSVNotValidException("did not work :(");
    }
});

I saw many SO posts regarding "jumping out of J8 foreach", but in there I only see how to extend the standard behavior etc. to somehow make it possible.

I want to know, why it is designed this way, that no checked Exception can be thrown (and catched in higher level afterwards) within a lambda expression in Java 8

I know technically, why this is the case (the functional interfaces simply don't define the throws part), but I don't understand, why it is chosen so. I only could explain this to myself, if you can solve all issues without the need of throwing an exception - but I don't actually think that this is the case.

P.S.: I don't want to use a RuntimeException (which would be possible to throw) as I don't like catching RuntimeExceptions. I want to use a checked Exception for this.

Cœur
  • 37,241
  • 25
  • 195
  • 267
BAERUS
  • 4,009
  • 3
  • 24
  • 39
  • 1
    Because checked exceptions are now uncool. – Boris the Spider Nov 27 '15 at 13:49
  • Thanks Tunaki, somehow I didn't see this SO post, as the answer there is what I searched and expected: It's rather a bug than a feature. Not what I hoped, but I'm pleased. How can I close this as a duplicate? – BAERUS Nov 27 '15 at 14:11
  • It's already closed as a dup. – Boris the Spider Nov 27 '15 at 14:11
  • 1
    The question has it backwards. It's not that we made a decision to do something special against checked exceptions in lambdas -- a lambda can throw any checked exception that the corresponding functional interface method permits, just like an anon class or a named subclass. What we did not do is decide to give lambdas *special permission* to do things with checked exceptions that other code that implements the same interface is not allowed to do. – Brian Goetz Nov 28 '15 at 14:46
  • 1
    @BAER Sorry, whatever post made you conclude this is a "bug" is incorrect. Others may want to declare this a bug or a failure, or may disagree with the design decisions behind the way things are, but its a leap of fantasy from there to "bug". – Brian Goetz Nov 28 '15 at 14:48
  • @BrianGoetz A broken specification is a bug is a bug is a bug. And when we can't simply replace `for`-loops with `forEach`-lambdas, the specification is broken because it significantly decreases the applicability of existing APIs in the context of functional programming and leaves far too much to be desired. – Christian Hujer Dec 20 '15 at 14:32

0 Answers0