NullPointerException on their stderr and continuing to run.The key question is: how can you be sure that the program recovered to internally consistent state after such exception? Printing of such exception clearly indicates a bug somewhere. I'd rather have such a program crash (the sooner the better) than continue to run and producing possibly garbage results, and maybe storing them in some files or in database.
What do you think?
Tags: java
7 comments:
Uhm, essay link is wrong?
Heh, thx, I forgot to fill in the URL. Fixed now.
NullPointerException is something you see quite often in J2EE world.
Actually you see quite a lot of runtime exceptions in Java. Something like failed assertions in GTK applications.
For example: there's no reason for crashing web application or whole JVM because someone forgets to check if the field is populated before comparison to some other field (dumb, but you see it quite often). Instead, container catches NullPointerException and redirects request to the error page.
Much better than crashing JVM.
Now, it's not just web applications - there are all sorts of containers that are expected to do the same thing. IDE for example. It has many submodules. You don't expect it to crash if one of the modules is faulty. You expect that it pops up error dialog, records the exception and continue to work.
OTOH. You've stumbled on something. Error handling in general.Error handling is something you don't learn from textbooks. Quite often you see code examples that just System.out.println everything with lame excuse it's just a demo, not a "real example". I hate those examples.
Ah, but isolation (containers, as you call them) is not a new thing. CGI scripts are isolated from the web server. Web servers usually fork, so when one dies, the others survive, etc.
But yes, I agree on error handling. All mechanisms are clumsy, and I hate Java's forced exception catching/declaring.
I see no excellence in the linked essay. The author rambles on and on about his admiration and awe for his idols, The Great Engineers. He repeats phrases by Richard Gabriel ("Quality Without a Name"), Paul Graham ("The Hundred Year xyz"), and Jamie Zawinski, without demonstrating any real understanding of the subject matter. For example, his distinction between Von Neumann machines and Lisp Machines is pure bunk. His blind praise of Emacs and blind dislike of IDE's is likewise bogus. His preference of Scheme over Common Lisp because the latter has grown "big and complex" (and, might I add, useful in the real world) shows his "Lisp is nice if you never want to use it" snobbery. The claim that "C++ is dumb" is contentious at best, and typical of someone who learned the language in the 1990s and never caught up. Finally, his current infatuation with Java is a good example of the same.
The author says, "I regurgitated the [OOP] hype myself." Well, sorry to say, he's still regurgitating, only now it's hype of a different kind: the Emacs hype, the Lisp/Scheme hype, the jwz/rpg/graham hype. He obviously doesn't even make an attempt to understand what makes Emacs and Scheme so great, and how this principle can be applied to other situations. He tries to convince us that he's changed, that his blind belief in OOP has been mitigated by years of experience, but it is obvious that he replaced one rigid set of beliefs with another. He's no better off.
Finally, anyone calling Mule "rock-solid" clearly has no clue. :-)
To Anonymous: Why I singled out this essay are his comments on currently popular scripting languages. Although, he *does* have a patronizing attitude, and *is* clueless at certain points. E.g. his comment about automatic flattening of lists in perl ("Not that you ever want it to work this way") is pure crap. This really comes in handy.
Java is crap, for the same reasons why
(sometimes in the Lower Pleistosene) something
called PL1 was crap.
In those days, the world was populated by programmers who wouldn't tolerate crap,
and PL1 died a quick and relatively painless
death. Today, the situation is different.
hl
Post a Comment