On Wednesday, March 30, 2011 12:50:37 AM UTC+2, KWright wrote: > > > Why are you criticizing the self-proclaimed "rough first draft" and totally > ignoring the whole point of my message? >
Because Cedric already explained why the point of your message wasn't particularly convincing. I'm calling you out as an extremely biased source that'll make java look bad at any opportunity, and evidently you do this without consciously even realizing it. I get the feeling that, whatever java does, if scala has an alternative way of doing it, you're against it, regardless of what "it" is. > Specifically, that using checked exceptions to provide an alternate return > is a flawed design, because it sidesteps the type system > No it doesn't. > and doesn't compose effectively > Yes it does. In the extremely rare scenario you want to do a series of parallel operations and the failure of one such operation by way of an exception is not meant to stop processing on any other, then... just build that. If for a particular case you truly feel the best design is to create a List<Either<Widget, IOException>> or some such then... just make that. collections are API constructs. If you want to have, say, a map call that works like this you can build it with (checked) exceptions just the same as with eithers, and if you build it for exceptions then you get the additional benefit of being able to apply this feature to unchecked exceptions as well. The difference between an unchecked exception and a checked exception (or Either return) is a grey line; there are cases where its a judgement call where there will never be any consensus about what is right: An unchecked exception, or, a checked exception / either / whatever other mechanism you prefer for conveying an expectable alternate result. This implies there are cases where you get one but wished it was the other and vice versa. Eithers are a real pain in this regard when trying to composition, because you need to do more work and the API needs to handle this complication as well: In practice you want to be able to treat both an Either return *and* an exceptional return the same way, but as these are two completely different constructs this is kinda complicated. The easiest way to do it is in fact to wrap the call in a closer and just throw the alternate result from the either, at which point we're right back where we started. Exceptions can all be handled uniformly. (HINT: What if you're in scala and composing a parallel sequence and one of them throws a runtime exception? What happens then? - scala has this 'problem' too) > My intent was not to make that aspect of Java syntax look artificially bad, > but to start with a familiar syntax before migrating to a language that > already has the functionality I'm advocating. I could have completed the > whole thing in Java, but it would have required an unwieldy amount of > supporting code, including either SAM types or the as-yet unfinalized Java 8 > closure syntax. > > You didn't even read a word that I said. You have the exact same issue in both scala and java (you want the result of a method call with a parameter that is itself the result of a method call), but in java you decide to labouriously create a bunch of final variables to store intermediate results, but in scala you inline it all, making the scala code look far smaller than the java code. A casual glance creates the wrong impression. > Perhaps you could cherry-pick a spelling mistake as well, which would then > *surely* demonstrate how everything I stated was completely invalid > > You just engaged in the logical fallacy that you're (falsely) accusing me of. Brilliant. -- 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.
