Example use case for Kevin's idea; a unit testing framework. You probably don't want that to stop at the first failure.
On Wed, Mar 30, 2011 at 8:40 PM, mP <[email protected]> wrote: > @Kevin > > I always thought failing early was a good thing, and yet you seem to > express tghe opposite and wish to aggregate success and failures together. > > Imagine an ATM that followed your example ignored a wrong PIN and continued > along w/ any requested withdrawals. > I would want to be in a car with you driving, lets ignore that red light > and go straight thru i want to get to the next green light, but dont worry > ive recorded both results. > > Im arguing your presenting the exact opposite of what most use cases want. > > Brilliant! > > On Wednesday, March 30, 2011 9:15:53 PM UTC+11, KWright wrote: > >> >> >> On 30 March 2011 01:55, mP <[email protected]> wrote: >> >>> @Kevin >>> >>> How is it better to embed your error(exception) handling together in such >>> a tight coupling w/ actual values? >> >> >> Each input can produce an Exception, independently. This is vital when >> working with concurrent code and it no longer makes sense to identify which >> of several Exceptions occurred first. >> >> >>> Try/catches may not be perfect buts its quite clear which are returned >>> values and which are the exceptions, and your continue w/ process because >>> everything is fine code is clearer separated from your error handling. >> >> >> Which is an argument against checked exceptions... >> >> While I'm more than happy with "normal" exceptions, it's my experience >> that the checked variety are used as alternate return values in >> circumstances that are far from exceptional. (e.g. "That string you gave me >> didn't happen to be a valid path? Oh no! This is a crisis, stop the world, >> summon Batman *and* Superman immediately!"). >> >> Checked exceptions and `Either` both force explicit coupling, but in >> different ways. `Either` has the advantage here of being a true type, and >> so is able to be passed to another method, or held in a collection. Checked >> exceptions have the advantage of playing nicely with other Java features >> (for example, `Either` is cumbersome without pattern matching and >> for-comprehensions) >> >> >> >>> Your sample shows exactly that its too easy to simply ignore the problems >>> because your happy you got some results. >> >> >> I claim the opposite. By allowing only a single failure to be reported, >> checked exceptions force you to suppress other errors if multiple failures >> occurred (such as working with a parallel array). They also make it >> painfully difficult to report partial success (i.e. 5 of those 7 Strings >> were valid paths). Again, you have to very explicitly ignore some problems, >> or build some risky high-maintenance code to capture them. >> > > So far only Alexey agrees w/ my statement. > > >> >> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "The Java Posse" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> >>> For more options, visit this group at >>> http://groups.google.com/group/javaposse?hl=en. >>> >> >> >> >> -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
