But what is an error condition? A business error or a lower level (VM
or OS) issue? It's a nice pattern for handling business logic errors
('your input is invalid' or 'a fulfulled order can't be cancelled')
but I treasure the ability to clearly separate the business logic from
the Exception handling (not error handling).On Mar 24, 7:57 am, Russel Winder <[email protected]> wrote: > > Which is, I believe, why the Go folk have eschewed exceptions in favour > of return codes. They solve the problem C has with this by using > multiple return values -- which avoids having to find obscure out of > band information channels or usurping the domain to carve out an error > information channel. > > value , errorCode = someOperationThatReturnsAValueAndAnErrorCode ( ) > if ( errorIndicated ( errorCode ) ) { > processError ( errorCode ) > } else { > processSuccess ( value ) > } > > Seems to be the idiomatic Go way of doing things. A return to a better > way or just backward looking? > > -- > Russel. > ============================================================================= > Dr Russel Winder t: +44 20 7585 2200 voip: sip:[email protected] > 41 Buckmaster Road m: +44 7770 465 077 xmpp: [email protected] > London SW11 1EN, UK w:www.russel.org.uk skype: russel_winder > > signature.asc > < 1KViewDownload -- 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.
