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 King<[email protected]> wrote:
> 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<[email protected]>
> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 [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
-~----------~----~----~----~------~----~------~--~---
