On 5 June 2012 20:55, Fabrizio Giudici <fabrizio.giud...@tidalwave.it>wrote:
> On Tue, 05 Jun 2012 21:48:09 +0200, Josh Berry <tae...@gmail.com> wrote: > > It is easy to contrive the situation where you don't want something to >> just go bang on the first error, though. Does anyone like the >> scenario where you get an error and fix it, only to be shown a new >> error that could have been additionally been reported in the first >> pass? >> > > It's easy to contrive that situation too, thinking of a consequentiality > so that the second error only happens in consequence of the previous one, > or it will happen only after you fix the previous one :-) > Sure, we see it all the time when compiling code. Doesn't stop we wanting to see more than one error when it fails though :) But I'd say that both examples are inappropriate. The point is that I want > perhaps something that processes the batch up to the end, then I go to the > log file and see the NPE where they happened, versus the fact that I have a > result set which is apparently ok, but now I have to dig into it to 1) > search for errors and then 2) rebuild the sequence of things that happened > back to the error. Which is where you'd use `Either`. Errors can still be propagated up the call stack through `Left` instances, but in a deterministic way that doesn't bail out in the middle of a long-running process. -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To post to this group, send email to javaposse@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
