Could you explain how checked exceptions sidestep the type system. I thought they were part of it.
On Tue, Mar 29, 2011 at 7:50 PM, Kevin Wright <[email protected]>wrote: > > > On 29 March 2011 22:34, Reinier Zwitserloot <[email protected]> wrote: > >> On Tuesday, March 29, 2011 1:27:01 PM UTC+2, KWright wrote: >>> >>> for(String path: Paths) { >>> final File file = new File(path); >>> final Widget widget = loadWidget(file) >>> widgetBuilder.add(widget) >>> } >>> >>> >> >>> val widgets = paths map { path => loadWidget(new File(path)) } >>> >>> >>> >> One of my pet peeves is language fanboys sneaking in irrelevant >> complications in the language they don't like. Which you've done here. If we >> take scala as a cue for how language should be styled, we could just as >> easily write: >> >> for (String path : paths) widgetBuilder.add(loadWidget(new File(path)); >> >> which is barely longer than the scala example and arguably simpler. >> >> > Why are you criticizing the self-proclaimed "rough first draft" and totally > ignoring the whole point of my message? Specifically, that using checked > exceptions to provide an alternate return is a flawed design, because it > sidesteps the type system and doesn't compose effectively - as demonstrated > by an example in which I apply a potentially exception-throwing operation to > multiple elements of a collection. > > The entire reason it's written like that is because I originally had > explicit exception wrapping around each line, which I subsequently removed > deeming it to obscure the purpose of the sample. At that point, it was > sufficient to demonstrate the core algorithm, and you'll even note that I > mentioned how necessary exception handling had been left out. > > 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. > > Perhaps you could cherry-pick a spelling mistake as well, which would then > *surely* demonstrate how everything I stated was completely invalid > > > >> As to the actual intent of your message - Cedric said all that needs to be >> said. >> >> >> -- >> 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. > -- 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.
