On Thu, 2011-03-24 at 00:34 +0000, Kevin Wright wrote: > It's quite simple... If there's something that can happen in your > method, and the caller *explicitly* needs to deal with it, then > there's a technique for dealing with that... It's commonly known as a > "return value". Yes, some form of "Maybe" or "Either" type combined > with lambdas makes this sort of thing a lot more concise and readable, > but it's certainly doable in Java, and the language isn't exactly a > stranger to boilerplate and verbosity!
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
Description: This is a digitally signed message part
