On 24 March 2011 09:16, Phil <[email protected]> wrote:
> 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.
>
>
Wrap and throw? Honestly... I'm sick and tired of writing classes that have
to deal with files, and having half the source code be for wrapping and
rethrowing. Of course, I *could* have those methods also declare
IOException, but that's just the boilerplate equivalent of an interest-only
mortgage - pay a small amount of boilerplate interest now, and still have to
pay the full cost later.
> 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.
>
>
--
Kevin Wright
gtalk / msn : [email protected]
<[email protected]>mail: [email protected]
vibe / skype: kev.lee.wright
quora: http://www.quora.com/Kevin-Wright
twitter: @thecoda
"My point today is that, if we wish to count lines of code, we should not
regard them as "lines produced" but as "lines spent": the current
conventional wisdom is so foolish as to book that count on the wrong side of
the ledger" ~ Dijkstra
--
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.
