public void handleWebRequest(String target, Request req, Response res)
throws Exception {
@Cleanup(release) Db db = worker.getDb();
db.doWhatever();
}
couldn't be simpler, really. @Cleanup is from project lombok, and it
ensures the db is released even if this method errors out. Note
On Aug 18, 5:27 am, phil swenson phil.swen...@gmail.com wrote:
Someone should short-circuit javac, since
checked exceptions really is just a figment of its imagination.
Done, sort of, if you use eclipse, at any rate. Install project lombok
and stick:
@SneakyThrows
on every method that you
In Scala you get the Either type. That is superior for most cases where
one might use checked exceptions in Java.
I have used that style in Java, but you usually don't make friends with it.
Peter
Michael Neale wrote:
What do people think of the scala approach of no checked exceptions -
I still believe that the main reason people hate checked exceptions is
that they have been used badly.
But I don't really like them either, I just dislike runtime exceptions
more ;-) The reason for that is that they hide things I might want to
know about when using an API. No one reads
The problem I feel is that an Exception should denote an EXCEPTIONAL
occurrence, and be able to list all things that can happen is just plain
impossible.
So switching to a fully checked exceptions would mean that every method
signature should mandatory include stuff like:
public void foo(Bar bar)
My sense is that Vince is correct; a beer on the porch is best
practice.
The porch is the best place for amateur punditry about vendor sports.
Now what Larry's gotta do next he slurred, tearing the tab off
another can of Weasels Extra Strength...
Or, you could sit on the porch and wonder what
Regarding closing JDBC resources when exceptions happen...
I like to have one close in the 'finally' block, but execute only when
the reference isn't null. (Yes, that's evil -- but JDBC's
SQLException is evil.)
What I'd like to do is to add any 'close()' SQLException to the
exception that may
Reinier Zwitserloot wrote:
Yes, an utopia with checked exceptions is probably pretty decent, but
as a practical matter they've been horribly abused. Not just by third
party libraries; the java core library is inconsistent in places and
has a lot of missing throws clauses in interfaces that
Lombok - is that named after Lombok in bali - near the island of
Java?
On Aug 18, 5:00 pm, Reinier Zwitserloot reini...@gmail.com wrote:
public void handleWebRequest(String target, Request req, Response res)
throws Exception {
@Cleanup(release) Db db = worker.getDb();
Is it really that bad? Most of the common exceptions shouldn't be there
at all, for example NullPointerException, ClassCastException and
ArrayStoreException are all just signs of a broken type system. Some of
the Errors seem unavoidable, but with the Exceptions I still prefer the
idea of
Proably would use a set of case classes I guess, but would end up
looking like a pretty version of that (someone like Viktor will
probably show us !).
On Aug 18, 9:11 pm, Peter Becker peter.becker...@gmail.com wrote:
Reinier Zwitserloot wrote:
Yes, an utopia with checked exceptions is
I may be way off in the weeds here -but if you aren't actually
working on a JVM language, is it really appropriate to turn up?
It would be a shame if John Rose missed an opportunity to chat with
Neal Gafter, cause I was trying to get him to autograph my mouse-pad -
if you see what I mean.
I
When you are done, watch the videos from Microsoft's reciprocal
conference; lang.net (two excellent 2009 videos with john rose for
example).
I second that, excellent video material:
http://www.langnetsymposium.com/2009/talks.aspx
Also don't forget to watch video from JAOO, i.e. Anders
Lombok looks interesting. Groovy makes this sort of code very
palatable too, instead of:
@Cleanup PreparedStatement ps = connection.prepareStatement
(sql);
@Cleanup ResultSet resultSet = ps.executeQuery();
while (resultSet.next()) {
// stuff
}
You
I guess should have used a different variable name in the last example:
db.eachRow(sql) { /* stuff */ }
Cheers, Paul.
On Tue, Aug 18, 2009 at 11:37 PM, Paul Kingpaul.king.as...@gmail.com wrote:
Lombok looks interesting. Groovy makes this sort of code very
palatable too, instead of:
Maybe what this discussion needs is some real-world anecdotes of checked vs
unchecked exceptions in production environments and how they helped or not to
save the day.
Alexey
2001 Honda CBR600F4i (CCS)
1992 Kawasaki EX500
http://azinger.blogspot.com
http://bsheet.sourceforge.net
On 18 Aug., 16:51, Alexey Zinger inline_f...@yahoo.com wrote:
Maybe what this discussion needs is some real-world anecdotes of checked vs
unchecked exceptions in production environments and how they helped or not to
save the day.
I would think it's a fairly real-world anecdote how no other
http://www.welie.com/patterns/
http://ui-patterns.com/
great resources
On Aug 18, 2009, at 1:34 AM, Jan Goyvaerts wrote:
Hello guys,
I'm asked to rework a search input screen with way too many input
controls to fit on a screen. I was wondering whether this would the
occasion to apply
On Aug 18, 11:03 am, Casper Bang casper.b...@gmail.com wrote:
On 18 Aug., 16:51, Alexey Zinger inline_f...@yahoo.com wrote:
Maybe what this discussion needs is some real-world anecdotes of checked vs
unchecked exceptions in production environments and how they helped or not
to save the
I understand the theoretical benefit of checked exceptions, but
reality trumps theory. They simply don't scale and lead to swallowed/
hidden exceptions.
I've seen quite a few open source APIs that have throws Exception in
them. And generally the open source APIs are done by some of the best
Yes. And the indonesian word for chili paste, which is also lombok.
(Spice up your java is the tag line, after all.)
On Aug 18, 1:22 pm, Michael Neale michael.ne...@gmail.com wrote:
Lombok - is that named after Lombok in bali - near the island of
Java?
On Aug 18, 5:00 pm, Reinier Zwitserloot
Exceptions aren't just for exceptional situations. This seems
perfectly legit to me:
public class BankAccount {
public void transferFundsTo(BankAccount other, int amount) throws
InsufficientBalanceException {}
}
The InsufficientBalanceException is not an exceptional situation. It
happens
Reinier Zwitserloot wrote:
Concrete examples:
Runnable does not let you throw Exceptions. Anyone up for defending
this grievous API design? The amount of annoyance that this is caused
me is almost limitless.
Well Runnable is really for cases where run() should eat any exceptions
other
On Aug 18, 11:21 am, Charles Oliver Nutter head...@headius.com
wrote:
Btw. how come invokedynamic is needed for the JVM when the DLR is
merely a library? Is it because the CLR already has dynamic dispatch
or because they don't seek the same performance profile as you do?
Forgot to
The way I normally think about it is, business exceptions are (usually)
checked exceptions. Error conditions are RuntimeExceptions.
-Mario.
--
I want to change the world but they won't give me the source code.
On Tue, Aug 18, 2009 at 19:56, Reinier Zwitserloot reini...@gmail.comwrote:
On Aug 16, 1:49 pm, Casper Bang casper.b...@gmail.com wrote:
Got it. I just don't find it's very popular to talk about these things
though, having aired my share of similar thought on this group and
witnessing the Kumbaya backlash with a dash of Microsoft demonization
thrown in for good
Forgot to mention...CLR does not have any support for dynamic
invocation. Even the dynamic keyword in C# 4 is just porcelain over
the DLR's dyncall pipeline.
Ah ok, that's what I was fishing for - not much info about this from
John Lam nor Jim Huginen.
Oh, and I think it's important to note
BGGA's checked exception handling is extremely complex. I don't like
it at all.
I'd much rather have a closure proposal where a method that takes a
closure that has tennant's correspondence principle is strictly
enforced by the compiler to keep the closure stack-safe. In other
words, legal
On Tue, Aug 18, 2009 at 3:13 AM, Peter Becker peter.becker...@gmail.comwrote:
What I would really like to see is a meet/or/disjunction/union operator
in the type system, with a case-like construct to resolve the resulting
types. Scala has two things that are halfway there (Either, case
I'm slightly embarrassed to admit I'm a fan of
http://bugs.sun.com/view_bug.do?bug_id=6534270
On Aug 15, 5:56 am, Jeff Grigg jeffgr...@charter.net wrote:
I like the beauty and simplicity of completely empty catch blocks. ;- OK,
some developers, to comply with corporate documentation
BGGA's exception transparency hinges on disjunctive types, of course...
James Iry wrote:
On Tue, Aug 18, 2009 at 3:13 AM, Peter Becker peter.becker.de
http://peter.becker.de@gmail.com http://gmail.com wrote:
What I would really like to see is a meet/or/disjunction/union
operator
Reinier Zwitserloot wrote:
BGGA's checked exception handling is extremely complex. I don't like
it at all.
You can gripe about that, but it is the only thing that really makes a
code block work normally.
If you have something like:
for ( ... )
{
// some code that throw
According to Joshua Engel's Programming for the Java VM, that is not
part of the verification algorithm. I had planned to do something
similar in Kijaro, and instead have NetBeans issue warnings when
neglecting to catch a checked exception - but I never really found out
how to override NetBeans
I really hate phrasing something like this as being a figment. That's
like saying that short and char are figments of the JVM's imagination
because it's all just bits.
None-the-less, the answer is that checked exceptions are enforced by Java's
static system and not by the JVM at all. So Scala,
On 19 Aug., 04:06, James Iry james...@gmail.com wrote:
I really hate phrasing something like this as being a figment. That's
like saying that short and char are figments of the JVM's imagination
because it's all just bits.
Yeah well, it depends how you look at it I suppose. I would also
I can think of a hack. But it's not a very nice one and probably has
limited use. You compile with throws Exception on the method and
then edit the method signature in the resulting byte code. Perhaps
easier than hacking javac.
--~--~-~--~~~---~--~~
You
On 19 Aug., 04:24, Christian Catchpole christ...@catchpole.net
wrote:
I can think of a hack. But it's not a very nice one and probably has
limited use. You compile with throws Exception on the method and
then edit the method signature in the resulting byte code. Perhaps
easier than
Maybe is good if something may or may not be there such in a dictionary
lookup. The element not being available is a normal occurrence in that case.
In the case of errors it would hide what the actual error was.
Peter
Michael Neale wrote:
Or Maybe - (in which case you don't care about the
Reinier Zwitserloot wrote:
Concrete examples:
Runnable does not let you throw Exceptions. Anyone up for defending
this grievous API design? The amount of annoyance that this is caused
me is almost limitless.
Where would that exception go?
Servlets require you to wrap checked exceptions
Let me just say that I fully agree with this post. I believe most people
look at the way checked exceptions are used and since that is mostly bad
they assume the whole idea is bad. Since I can think of nicer solutions
with checked exceptions for pretty much everything people complain about
I
phil swenson wrote:
[...]
Another issue I didn't mention is checked exceptions pollute the
interface. Lets say you have a public API (interface) and add a new
exception type. This makes every consumer of your API's code break.
This violates the concept of having an API contract. So with
I agree that there is a blurry line between exception and alternate
return value and as stated elsewhere I would prefer a union type in most
cases.
In your example the exception should be reasonable exceptional, though
-- after all people should not try a transfer unless they checked the
On Tue, Aug 18, 2009 at 7:11 PM, Casper Bang casper.b...@gmail.com wrote:
Yeah well, it depends how you look at it I suppose. I would also claim
generics to be a figment of the JVM's imagination, since you can not
implement ComparableInteger and ComparableBigInteger due to it
being an
Well actually, Stephen Colebourne has made is real easy to hack on the
Java compiler - especially small hacks strictly at the parser level,
which we're talking about here. If you want to try it check out a
branch of Kijaro, locate the Check.java class and the methods matching
the signatures:
especially small hacks strictly at the parser level
Ok yeah, I know technically it's at the semantic analysis level, but I
always think of the entire front-end (lexer, parser, semantic
analysis) as just the parser. Somewhat simpler than optimizer and
emitter.
/Casper
Java Exception handling technique number 284. Eat.
http://twitpic.com/efxij
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups The
Java Posse group.
To post to this group, send email to javaposse@googlegroups.com
To
46 matches
Mail list logo
