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 how I
just toss a 'throws Exception' on there. This is a servlet; it's
effectively an entire application all by itself. That kind of broad
context is allowed to throw whatever the heck it wants. The code that
calls into this code catches throwable, because if a servlet errors
out, even with something drastic like, say, an InternalError, it
should not take the whole webserver down with it. The code that
catches this does some sorting work on the exception in question, and
targets a different log file if it seems particularly nasty (such as
out of memory, internalerror, virtual machine error, and a few
others), but that's really an implementation detail. The point is: The
gazillion different instances of 'handleWebRequest' are as simple as I
could make them.
NB: The db object isn't passed in primarily because not all these
handlers need one, and the db engine is an entirely separate module,
so I'd rather avoid adding a dependency there. If I didn't have
lombok, I would make Db 'lazy' and grab a connection only when a
request happens, so that you don't have to try/finally this stuff, and
pass a Db object into the handleWebRequest call.
For you JDBC users, I suggest you go play with projectlombok.org.
Here's Christian Catchpole's code sample without lombok:
PreparedStatement ps = connection.prepareStatement(sql);
try {
ResultSet resultSet = ps.executeQuery();
try {
while (resultSet.next()) {
// stuff
}
} finally {
resultSet.close();
}
} finally {
ps.close();
}
and here's the same thing with lombok:
@Cleanup PreparedStatement ps = connection.prepareStatement
(sql);
@Cleanup ResultSet resultSet = ps.executeQuery();
while (resultSet.next()) {
// stuff
}
If you have a need to handle SQLExceptions locally (I would like to
state again that if you are forced to do this, your framework sucks
and you should fix it!), it would turn into:
try {
@Cleanup PreparedStatement ps = connection.prepareStatement
(sql);
@Cleanup ResultSet resultSet = ps.executeQuery();
while (resultSet.next()) {
// stuff
}
} catch ( SQLException e ) {
//What are ya gonna do now?
}
rule of thumb: If you can't do anything useful in your catch block
other than log and/or wrap it, you're doing it wrong.
And to the genius who mentioned beep(): Whoa. Did not know about it.
Evil! Muhahaha!
On Aug 18, 3:29 am, phil swenson <phil.swen...@gmail.com> wrote:
> I'm happy to see all the runtime exception advocates on here.
> Definitely not the mainstream view. Smart crowd :)
>
> I would love to see some example of how you guys write JDBC code.
> JDBC code is usually the most heinous of all with all the SQLException
> and resource handling crap you have to do.
>
> Please post a snippet :)
>
> On Aug 17, 6:47 pm, Michael Neale <michael.ne...@gmail.com> wrote:
>
>
>
> > The only sane way is this:
>
> > try {
>
> > .. your code here
>
> > } catch (Throwable t) {
>
> > for (int i =0; i< 1000; i++)
> > java.awt.Toolkit.beep();
> > System.exit(-1);
>
> > }
>
> > Sometimes can use a Runtime.exec to delete the home directory for good
> > measure, but that means platform specific code.
>
> > On Aug 18, 8:58 am, Casper Bang <casper.b...@gmail.com> wrote:
>
> > > For that we have Runtime().getRuntime().addShutdownHook() no? That's
> > > what I used anyway with JSR-296, where Hans Muller had hardwired the
> > > System.exit() call in the framework.
>
> > > /Casper
>
> > > On 17 Aug., 23:11, Peter Becker <peter.becker...@gmail.com> wrote:
>
> > > > Jess Holle wrote:
> > > > > Peter Becker wrote:
>
> > > > >> While I agree that you can have shared state, the scenario I had was
> > > > >> a
> > > > >> clean worker: some data goes in before the thread gets started, other
> > > > >> data comes out at the end.
>
> > > > >> System.exit is a bad idea generally since you don't really know who
> > > > >> is
> > > > >> going to use your code in the future. If you call System.exit in your
> > > > >> average Tomcat installation you'll probably take it down with you. I
> > > > >> tend to restrict the System.exit calls to main(..) methods.
>
> > > > > Low-level code shouldn't be catching VirtualMachineError -- it should
> > > > > always re-throw it.
>
> > > > I agree. But between the likelihood of this error being raised and the
> > > > damage done if you catch it when you shouldn't the risk seems quite
> > > > acceptable. Again: it is highly dependent on what your application is, I
> > > > would certainly not recommend this for a mission or even life critical
> > > > section of code.
>
> > > > > Only top-level thread handlers should catch these errors and call
> > > > > System.exit().
>
> > > > And what happens to other threads? If you call System.exit you should
> > > > have global knowledge of all application threads and their current
> > > > state. Even in the presence of a VirtualMachineError it is probably
> > > > better to try a clean shutdown. Calling System.exit could leave a lot of
> > > > things in inconsistent state that will be hard to recover from. Are all
> > > > your system's boundaries transactional?
>
> > > > Peter
--~--~---------~--~----~------------~-------~--~----~
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 unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
