On 31 March 2011 00:40, 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. >
So you have an Either[Exception, AuthenticationToken] containing only an exception, from which you pass the non-existent token to the withdraw() function. I think not... > 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. > An exception occurs when there is a failure mid-process. A traffic light is something you check BEFORE the process of driving through the junction, how is this even remotely relevant? Are you proposing you should discover the red light half-way across then reverse time if necessary? > Im arguing your presenting the exact opposite of what most use cases want. > > No, you're demonstrating that you haven't considered the particular issues that I raised. Specifically relating to the checked-exception-as-an-alternate-return-type use case, and how such "alternate returns" aren't readily composed when working with collections or operations running in parallel. You've merely scanned what I said, mentally flagged it as anti-exception without looking at the content in any depth, and then criticized based on that false evaluation. > 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. > -- Kevin Wright gtalk / msn : [email protected] <[email protected]>mail: [email protected] vibe / skype: kev.lee.wright quora: http://www.quora.com/Kevin-Wright twitter: @thecoda "My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra -- 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.
