Checked exceptions *do* force you to handle or re-throw. I have absolutely nothing against unchecked exceptions here, and I'm sorry if I gave that impression to anyone, they're an incredibly useful mechanism for dealing with errors that truly are outside of the normal flow control.
On the other hand, there are situations where it's possible for a function to return two divergent and valid possibilites. I'm simply questioning the choice to mark such valid cases as being "exceptional", and explaining how things are often done this way because exception handlers are the closest alternative in Java to true pattern matching. 2010/9/22 Cédric Beust ♔ <[email protected]> > You are, again, completely missing the point of exceptions: they don't > force you to handle the error at the call site. > > The approach you are recommending leads to this kind of spaghetti > code<http://www.kirit.com/Handling%20COM%20errors%20in%20C%2B%2B> (C) > or this > one<http://stackoverflow.com/questions/2137357/getpasswd-functionality-in-go/2138163#2138163>(Go). > In these two examples, notice how the error handling is completely > polluting the logic and making the code hard to follow. > > Anyone who has programmed Win32 15 years ago can certainly remember the > maintenance nightmare caused by HRESULT. We don't want to go back there. > > -- > Cédric > > > On Wed, Sep 22, 2010 at 5:34 AM, 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. >> >> On 22 September 2010 13:19, Ricky Clarkson <[email protected]>wrote: >> >>> The point is that it's your choice what to do. Using Either does not >>> mean you have to write lots of if statements, though you can if you like. >>> >>> >>> On Wed, Sep 22, 2010 at 12:22 PM, Miroslav Pokorny < >>> [email protected]> wrote: >>> >>>> How is either any better than letting catching an exception or letting >>>> the code continue in the original spot. One gets a split off into a >>>> everythings ok here a file, or jump to there and process the problem ? >>>> Using >>>> Either ends up being "more" code because we get the branch for free with >>>> exceptions...And given FileCreation failed is an exception the flow will be >>>> most likely at least a bit different. Continuing on and checking later does >>>> not seem to make much sense most of the time. >>>> >>>> -- >>>> 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. >>>> >>> >>> -- >>> 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. >> > > > > -- > Cédric > > > -- > 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.
