@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.
