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 would do: sql.eachRow(sql) { /* stuff */ } On Tue, Aug 18, 2009 at 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(); > 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 -~----------~----~----~----~------~----~------~--~---