www.carfield.com.hk

suggestion.txt

2021-01-27T13:55:59Z

With nice examples - http://www.javaspecialists.eu/archive/Issue162.html

Try to do better working than log and quit - http://blog.objectmentor.com[..]9/01/05/abstracting-away-from-exceptions

http://www.makinggoodsoftware.com[..]ceptions-in-java-4-basic-considerations/

Exception Patterns - http://c2.com/cgi/wiki?ExceptionPatterns

The Scourge of Error Handling, "go" experience - http://www.drdobbs.com[..]5_h&elq=2c4502fb959647fd9ad16dc5c0f7d75d

http://www.flowstopper.org[..]13/11/java-should-i-assert-or-throw.html

https://vanilla-java.github.io[..]/06/21/Reviewing-Exception-Handling.html

https://blog.darrien.dev[..]s/error-handling-in-java-is-error-prone/

Why use exception instead of error code.txt

2018-11-10T16:56:20Z

A detailed explanation - http://gamearchitect.net/Articles/ExceptionsAndErrorCodes.html

What are exceptions? - https://binkley.blogspot.com/2018/11/what-are-exceptions.html

problem of using exception for control flow.txt

2008-06-25T01:59:02Z

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

Handle exception at event.txt

2008-03-17T17:25:24Z

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/

anti-pattern of exception.txt

2007-07-12T08:20:21Z

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

check or uncheck.txt

2007-06-13T17:14:39Z

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

handle exception in finally.txt

2007-02-27T04:31:48Z

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

Using stacktrace to know call hierarchy.txt

2006-02-24T08:14:21Z

Sometime it useful to know call hierarchy even if it is not exception case

http://jroller.com/page/henribenoit?entry=where_am_i_called_from

cool exception message.shtml

2006-01-08T11:23:48Z

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)