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?
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].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
