On 22 September 2010 14:32, Kevin Wright <[email protected]> wrote:
> The difference becomes more apparent when your code looks like this:
>
> try {
> val handle = fileOpen(fileName)
> doSomethingWithFile(handle)
> moreFileOps(handle)
> yetSomethingElse(handle)
> .
> .
> .
> another functionUsingTheFile(handle)
> .
> .
> .
> .
> .
> keepGoing(handle)
> .
> .
> .
> .
> .
> promiseThisIsTheLastOne(handle)
> } catch {
> case Exception(e) => logError(e)
> }
>
>
> Now answer quickly:
> - where might the exception have been thrown?
> - which of those methods have side-effects? Does it matter? How do you
> determine what changes to roll-back when an exception is thrown?
> - does it matter if the file is "not found" halfway through, instead of
> when you first opened it? Would the correct response be different in these
> cases?
>
but don't you have the same problem with Either / error codes?
if the developer can sequentially call moreFileOps(handle),
yetSomethingElse(handle), etc. without checking the return value then they
can fall into the same trap...
On 22 September 2010 14:16, Miroslav Pokorny <[email protected]>wrote:
>
>> On Wed, Sep 22, 2010 at 10:34 PM, Kevin Wright
>> <[email protected]>wrote:
>>
>>> Lets compare...
>>>
>>> Apologies for using Scala, my intent here is to demonstrate the
>>> differences in the techniques using a language that supports both styles,
>>> not specifically to advocate Scala.
>>>
>>> val fileName = """c:\autoexec.bat"""
>>>
>>> // using either
>>> fileOpen(fileName) match {
>>> case Left(handle) => doSomethingWithFile(handle)
>>> case Right(error) => logError(error)
>>> }
>>>
>>> //using try/catch
>>> try {
>>> val handle = fileOpen(fileName)
>>> doSomethingWithFile(handle)
>>> } catch {
>>> case Exception(e) => logError(e)
>>> }
>>>
>>>
>>> The try/catch example has a couple of extra lines, but that's hardly
>>> significant. More importantly, as the amount of code grows between the try
>>> and the catch, possible points of divergence for control flow become
>>> increasingly unclear. This is high-risk for
>>> causing maintenance difficulties in the future. using Either, on the other
>>> hand, suggests that "file found" and "file not found" are equally valid
>>> non-exceptional outcomes, and places them on a level footing as regards the
>>> flow of control.
>>>
>>
>> So how is adding lots of cases any clearer than adding lots of catches ?
>> Just about all the tokens and statements are in exactly the same place and
>> order, its just the "decorations" and syntax that looks different ? I cant
>> see how this could be said to be any clearer from the user of an api...
>>
>> --
>> 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]<javaposse%[email protected]>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/javaposse?hl=en.
>>
>
> --
> Kevin Wright
>
> mail / gtalk / msn : [email protected]
> pulse / skype: kev.lee.wright
> twitter: @thecoda
>
> --
> 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]<javaposse%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/javaposse?hl=en.
>
--
Cheers, Stuart
--
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.
