It is part of the type system, it just isn't a value.  Like void.

On Tue, Mar 29, 2011 at 8:14 PM, Kevin Wright <[email protected]>wrote:

>
>
> On 30 March 2011 00:02, Ricky Clarkson <[email protected]> wrote:
>
>> Could you explain how checked exceptions sidestep the type system.  I
>> thought they were part of it.
>
>
>
> Sure, take my example again, cut down to the bare minimum.
>
>  Widget loadWidget(final File file) throws WidgetParseException { ... }
>
> final List<String> paths = ImmutableList.of("/usr/home/...", ...);
>
> final List<Widget> results = new ArrayList<Widget>();
> for(String path: Paths) { results.add(loadWidget(new File(path))); }
>
>
> How can I then try and load a widget for every single path in `paths`, and
> capture the outcome in `results`, regardless of success or failure.
>
> If 'checked exception' was a type, then I'd be able to create a
> List<CheckedException>, and assign the results from failed loadWidget
> attempts to that list.
>
>
>>
>> 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.
>>>
>>
>>
>
>
> --
> 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.

Reply via email to