On 28 March 2011 14:43, Phil <[email protected]> wrote:

> Now I thought we were discussing how to deal with checked and
> unchecked exceptions in Java (the language, not the platform). That
> much was clear to me at the beginning, at least! The solution for me
> is to be pragmatic and adopt the most appropriate approach (catch and
> handle, throw, wrap and throw... there are other choices too) for a
> given situation although I lean towards a particular style. We all
> have our own preferences, and as a freelancer I generally have to fit
> in with the coding style of the project, rather than warp the project
> development standards around my own preferences. I certainly don't
> expect to persuade anybody that approach X is better than approach Y.
> I'm interesting in using the one that is right for a given situation,
> that allows me to provide a solid piece of software that works (and
> fails) in a predictable fashion.
>
> On that basis, moving language is not something I would ever envisage
> being discussed as a solution. Choice of language is the kind of
> decision that is made early in architectural development, where for
> example a case might be made for using a DSL or functional language to
> better express a part of the overall technical solution.
>
> With exception handling however we are talking about coding patterns
> which is more of a low level design/code decision. You want the same
> coding style applied by all your developers to deliver a uniformly
> styled code base that is then easier to maintain. So a suggestion to
> change language would not be viewed sensibly as a way of dealing with
> the checked/unchecked conundrum at that level. Repeating it puts you
> on weaker ground, not stronger - people start to question motives and
> objectivity. I don't think you are advancing the cause of other JVM
> languages by doing this... maybe a new thread around why to choose
> another JVM language instead of Java for a new project. To propose
> another language at an early enough stage of a project I'd expect to
> be asked to provide technical background to show why my proposal is
> worth considering, and also tie in business considerations such as
> cost, availability of skilled resources, maturity of the language...
>
>
I've seen 3 discussions here:

1. How to work around the current status-quo with regards to problems caused
by checked exceptions
2. Speculation on how Java (the language) might be improved in a future
version, which leads to...
3. A general discussion of checked exceptions and alternate ways to get
equivalent behaviour without the problems they cause (including examples
from other languages)

Where:

#1 seems to have been resolved to the satisfaction of all present by either
accepting the status-quo or by using chuck or @sneakyThrows

#2 produced a general consensus in favour of simply turning them off, or
otherwise ignoring them via new language syntax

#3 agreed with #2, but also raised the possibility of monads as an
alternative way to offer the same functionality without many of the problems
caused by Java's checked exceptions.  This being a feature that could
theoretically be added to the Java standard library, alongside such niceties
as tuples and closures.

Once the discussion moved to the question of how Java might be improved in
the future... it became very reasonable to give examples from other
languages (especially those already on the JVM), and demonstrate alternate
directions in which Java might evolve.



> On Mar 28, 12:31 pm, Kevin Wright <[email protected]> wrote:
> >
> > You can move language, but still remain on the Java platform.  That was
> kind
> > of my point...
> >
>
> --
> 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.

Reply via email to