Comments on: Errorhandling Ruby vs. Java

By: lenciel » 博客文章 » 昨日搜刮

lenciel » 博客文章 » 昨日搜刮 — Mon, 19 Mar 2007 15:17:17 +0000

[...] Errorhandling Ruby vs. Java # [...]

By: Frank Spychalski

Frank Spychalski — Mon, 12 Jun 2006 08:26:22 +0000

Neutronica, I want both

By: Neutronica

Neutronica — Mon, 12 Jun 2006 02:12:17 +0000

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.

By: Neutronica

Neutronica — Mon, 12 Jun 2006 02:11:03 +0000

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

By: Frank Spychalski

Frank Spychalski — Tue, 04 Apr 2006 07:16:02 +0000

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

By: Robert Fisher

Robert Fisher — Mon, 03 Apr 2006 17:51:06 +0000

“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();
}

By: Jason

Jason — Sat, 01 Apr 2006 20:55:09 +0000

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.

By: Frank Spychalski

Frank Spychalski — Sat, 01 Apr 2006 19:25:59 +0000

notany, Peter: thanks for the pointers

By: Peter Cooper

Peter Cooper — Sat, 01 Apr 2006 18:42:27 +0000

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.

By: notany

notany — Sat, 01 Apr 2006 15:21:35 +0000

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.

By: Frank Spychalski

Frank Spychalski — Sat, 01 Apr 2006 11:56:13 +0000

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?

By: mal

mal — Sat, 01 Apr 2006 10:49:29 +0000

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.