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 <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
-~----------~----~----~----~------~----~------~--~---
