|
Sat
1
Apr '06
|
|
At my daytime job I had to rewrite a class which sends a Message to a Queue. Sounds simple? With EJB3 it is reasonably simple and can be done in around 10 lines of code involving lots of lookups. But if you are looking for a reliable solution which works even when the application server reboots every once in a while your code gets messy. My current solution has 120 lines of code and there are still some things to add like buffering of unsent messages.
Bloated Exceptionhandling
Why do I have to write so much more code to get a reliable solution? Part of the blame is on Java, because of its verbose exception handling – there is no elegant way of catching 2 or more exceptions[1] without catching Exception or Throwable, which I try to avoid where possible. Ruby has this simple solution compared to the bloated solution in java, especially with EJB where you have to catch half a dozend different exceptions.
begin
eval string
rescue SyntaxError, NameError => boom
print "String doesn't compile: " + boom
rescue StandardError => bang
print "Error running script: " + bang
endRetry
Repeating whole blocks of code needs too much code, too. Ruby has the retry command, which restarts the current block:
c = 0
for i in 1..100
tries = 0
begin
c = c + 1 # dummy code
if c % 4 != 0 # to create
puts "failed for #{i}" # a few
raise "uups" # exceptions
end
puts "action #{i}"
rescue
puts "rescue"
tries = tries + 1
retry if tries < 3
end
endThis is just another name for goto, which might be harmful. Actually, I wouldn’t use this solution anyway because there is a better, more reusable way, to achieve the same.
closures
In ruby, it is possible (and very simple) to pass some code to a method. This allows me to create a method which excecutes my code multiple times, if an exceptions occurs:
def try(max_tries = 3)
tries = 0
begin
yield
rescue
puts "rescue"
tries = tries + 1
retry if tries < max_tries
end
end
c = 0
for i in 1..100
try do
c = c + 1 # dummy code
if c % 4 != 0 # to create
puts "failed for #{i}" # a few
raise "uups" # exceptions
end
puts "action #{i}"
end
endWhen I started this article, I just wanted to write a short rant about the missing features for errorhandling in java. While writing, I noticed that Ruby has them. Perhaps that’s the reason why I enjoy programming in ruby so much 
[1]to clarify this point just for Jason: In general, there is no elegant way of catching two or more exceptions. If you look at the number of direct subclasses in java.lang.Exception, it is nearly impossible to catch the exceptions you want using a superclass without catching some ‘innocent bystanders’.
I would very much like to see a elegant solution which catches only java.sql.SQLException and java.util.concurrent.TimeoutException, you may use as much OOP and polymorphism as you like. This might not be the fault of the language but the plattform but as I cannot get one without the other, it doesn’t really matter to me. Don’t get me wrong, I think Java is pretty damn good, but there is still a lot of room to improve. And Ruby is showing some of the things which can be done better.
What are you using as a Queue in Ruby? I am looking for a good message que to use with ruby. Something really robust and fast.
The queue I was refering to, was a Java JMS Queue within JBoss. For what do you need a queue and what kind of problem are you trying to solve with it?
Everyone who is intrested digging deeper into Rubys error handling and it’s pros and cons and philosophical motivations behind it, should read the following paper (now online). Like many other things, Common Lisp has the most advanced condition system in existence. Ruby’s is restricted version of that.
Condition Handling in the Lisp Language Family
http://www.nhplace.com/kent/Papers/Condition-Handling-2001.html
This paper appears in Advances in Exception Handling Techniques,
edited by A. Romanovsky, C. Dony, J.L. Knudsen, and A. Tripathi.
This book, published in 2001, is part of Lecture Notes in Computer Science, Volume 2022,
published by Springer.
Two queue ideas for Ruby.. Spread is a good messaging system that’s been around years and there’s a good Ruby client library. Just been playing with it, very nice. Alternatively, BerkeleyDB has a Queue mechanism. Both of these are mature technologies.
notany, Peter: thanks for the pointers
This article is written very poorly. You need to supply an example that compares and contrasts java code vs. the ruby code. Maybe code the same solution in both languages. As far as your comment ” there is no elegant way of catching 2 or more exceptions without catching Exception or Throwable” is concerned, you are wrong. You need to look into OOP and polymorphism. Also, look at some design pattern books, then maybe you can start posting comments why you think ruby is so much better than java. ps, your site breaks in the Opera browser.
“I would very much like to see a elegant solution which catches only java.sql.SQLException and java.util.concurrent.TimeoutException”
try {
foo();
} catch(java.sql.SQLException e) {
sqle.printStackTrace();
} catch(java.util.concurrent.TimeoutException e) {
e.printStackTrace();
}
Again, I should have been more specific
I usually have to do more than just print out the stacktrace. This errorhandling is sometimes the same for different Exceptions. This leads to solutions like the one below, which I don’t consider very elegant, compared to the Ruby solution:
try {
foo();
} catch(java.sql.SQLException e) {
handleEx(sqle);
} catch(java.util.concurrent.TimeoutException e) {
handleEx(e);
}
private void handleEx(Exception e) {
…
}
I would like to see:
try {
foo();
} catch(java.sql.SQLException, java.util.concurrent.TimeoutException : Exception e) {
…
}
I admit, this is just syntactic sugar but I like sugar
Actually, I don’t think you want the above, either: you want a retry keyword…
Without thinking about it much, the best I could come up with is something like this:
public static Object block(final IRetry block_,
final Class[] catch_,
final int tries_)
throws RuntimeException {
Exception finalException = null;
for (int i = 0; i
Eh. It got chopped. Event w/ the yicky chunk above you should be able to figure out what I’m about: suffice to say, much nicer in Ruby, and this might be a usecase for AOP.
Neutronica, I want both
[...] Errorhandling Ruby vs. Java # [...]