As far as Java-the-language is concerned, the only difference between exceptions and some other way of reporting alternative results of operations is ease of flow control. A thrown exception allows you to divert to an alternate execution path. That's all it is, really. If you wanna design a method that can have partial failures and report on them accordingly, whether a container exception (wrapping individual exceptions expressing partial failure) is thrown, an Either-like construct is used, or an externally visible state is altered from within the method -- it's all about your design choices then.
Ask yourself what the right thing to do is in the case of total success, total failure, and partial failure. Identify truly different ways of handling those and you can design your API accordingly. We're up against the same design problem we mentioned before (API designer may not have the benefit of complete foresight of how their API will be used), but overall, it's still possible to make some decisions here. Exceptions or no exceptions, the sky is not falling. Alexey ________________________________ From: Kevin Wright <[email protected]> To: [email protected] Cc: mP <[email protected]>; Cédric Beust ♔ <[email protected]>; Casper Bang <[email protected]> Sent: Wed, March 30, 2011 6:15:53 AM Subject: Re: [The Java Posse] Re: How to deal with CheckedExceptions 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. -- >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] 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. -- 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.
