Checked or unchecked aside, one reason I like the separation between
the old C-style return value approach and exceptions is that an
exception is a clear statement that something very much out of the
ordinary has happened, something that the higher level business logic
is not expected to handle.
This clean separation has a cleansing effect on the code as well as
making it easier to look at unfamiliar code and separate business
logic from exception handling.
Personally I sit in the 'handle it immediately or wrap and throw'
camp. Not least because the most realistic place to handle the
exception is inside the method that it occurred. The further away from
the exception the handling code resides, the harder it becomes to code
a specific recovery action. So as a rule of thumb my classes will not
throw exceptions. If exceptions play an important part in the overall
component (for example in some kind of remote interface/adapter where
an exception will manifest if the thing on the other side is broken/
uncontactable) then this would be presented to the outside world as a
state change event (e.g. connection lost) rather than as an exception.
There are plenty valid scenarios where exceptions should be caught and
handled, applying a blanket rule 'throw and forget' is almost as bad
as 'catch(Throwable t) {}' and indicates a weakness in the software
architecture.
On Mar 24, 7:57 am, Russel Winder <[email protected]> wrote:
> 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
> < 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.
