Wed Jun 25 01:59:02 GMT 2008
From
/weblog/design/exception
Other than harder to read, this approach is easier to have side effect, consider the following case:
// Code which fail
public String service() {
try {
// a lot of other code....
return getRecord();
} catch (SQLException re) {
return "defaultRecord";
}
}
private String getRecord() throws SQLException {
PreparedStatement ps = getConnection().prepareStatement("select something from sometable");
try {
final ResultSet rs = ps.executeQuery();
try {
if (rs.next())
return rs.getString(1);
else
throw new NotFoundException();
} finally {
rs.close();
}
} finally {
ps.close();
}
// definition of NotFoundException, analog to IOException and FileNotFoundException
public final class NotFoundException extends SQLException {....}
The idea is, for any database problem, just return default value. However, if someone change the interface of NotFoundException to
public final class NotFoundException extends RuntimeException {....}
Then it break service() silencely :-/ Some to it is better to have
// Code which fail
public String service() {
try {
// a lot of other code....
return getRecord() == null ? "defaultRecord" : getRecord();
} catch (SQLException re) {
// proper exception handling
}
}
private String getRecord() throws SQLException {
PreparedStatement ps = getConnection().prepareStatement("select something from sometable");
try {
final ResultSet rs = ps.executeQuery();
try {
if (rs.next())
return rs.getString(1);
else
return null;
} finally {
rs.close();
}
} finally {
ps.close();
}
(google search)
(amazon search)
Mon Mar 17 17:25:24 GMT 2008
From
/weblog/design/exception
To prevent no one notice there is problem
What the code is trying to do is make sure is that any exception thrown is brought to the attention of the user. I’ve been looking at a few approaches to help catch and handle these exceptions without the developer having to explicitly catch them at the UI level.
You can create your own EventQueue, and have it catch uncaught exceptions when dispatching methods
http://www.magpiebrain.com[..]2004/07/21/catching-uncaught-exceptions/
(google search)
(amazon search)
Thu Jul 12 08:20:21 GMT 2007
From
/weblog/design/exception
Mostly agree, however, why do we need NoSuchMethodException? Why we don't just don't implement that method? If this is required by the interface, why we implement an interface but not complete the contact?
http://today.java.net[..]/06/exception-handling-antipatterns.html http://softarc.blogspot.com[..]06/exception-handling-anti-patterns.html
(google search)
(amazon search)
Wed Jun 13 17:14:39 GMT 2007
From
/weblog/design/exception
Checked or unchecked? Not sure, seen all exception is unchecked are ok for me
To summarize Java orthodoxy: checked exceptions should be the norm. Runtime exceptions indicateprogramming errors.
I used to subscribe to this view. However, after writing and working with thousands of catch blocks, I've come to the conclusion that this appealing theory doesn't always work in practice. I'm not alone. Since developing my own ideas on the subject, I've noticed that Bruce Eckel, author of the classic book Thinking in Java, has also changed his mind. Eckel now advocates the use of runtime exceptions as the norm, and wonders whether checked exceptions should be dropped from Java as a failed experiment
http://www.mindview.net/Etc/Discussions/CheckedExceptions Other discussion of checked or unchecked -
http://www.theserverside.com/news/thread.tss?thread_id=35586 http://www.infoq.com[..]2007/05/removing-java-checked-exceptions
(google search)
(amazon search)
Tue Feb 27 04:31:48 GMT 2007
From
/weblog/design/exception
This blog discuss the code at finally can affect code at catch block -
http://mult.ifario.us/articles/2006/07/26/java-brain-teaser
ExternalResource resource = resourceManager.open();
Throwable e1 = null;
try {
// Use the resource (stream, db connection, ...)
} catch (Throwable e) {
e1 = e;
} finally {
try {
resource.close();
if (e1 != null) throw e1;
} catch (Throwable e2) {
// Pretend e2 doesn't already have a cause...
if (e1 != null) e2.initCause(e1);
throw e2;
}
}
http://bagotricks.com[..]06/02/06/dropping-the-ball-er-exception/ or this, can be better looking
try {
InputStream is = new FileOutputStream("hello.txt");
try {
is.write("hello");
finally {
is.close();
}
} catch (IOException e) {
e.printStrackTrace();
}
http://jroller.com/page/davinci?entry=finally_in_catch
(google search)
(amazon search)
Sun Jan 08 11:23:48 GMT 2006
From
/weblog/design/exception
From a very good jpeg meta data extractor -
http://drewnoakes.com/code/exif/
mention the solution at exception message
com.drew.metadata.MetadataException: Tag Image Width has not been set -- check using containsTag() first
at com.drew.metadata.Directory.getInt(Unknown Source)
(google search)
(amazon search)