views:

165

answers:

2

ok, im working in a j2ee project that has 2 branches in the repo and i'm ordered to mix them.

i was coding and then netbeans ask me "unreported exception blah bla bla must be caugth or declared to be thrown" and gives me the choice of just handle each exception or just throw it hoping someone else catches.

The classes i'm working with are these:

DataBase - DataObject - PersonDB(I'm working here)

DataBase an abstraction of the DBMS(supports a couple of them)

DataObject is just the CRUD, type conversion between the DBMS and java , and some reflection things for generality, it uses Database as a member variable

PersonDB is a map of the fields in the table called person to java types, this class extends DataObject

Now in the version 1(just the name actually worked in parallel) catch all the exceptions where they are produced for example in the class DataBase:

try {
        Class.forName(this.driver);
    } catch (ClassNotFoundException ex) {
        Logger.getLogger(BD.class.getName()).log(Level.SEVERE, null, ex);
    }

or in the DataObject class catching: SQLException, NoSuchFieldException, IllegalArgumentException

now on version 2 all that is left to the up caller like this:

public BD (String Adriver, String Ahost, String Abase, String Alogin, String Apassword) 
throws java.lang.ClassNotFoundException { ... }

which is the best way to go in your oppinion in this kind of issues, specially if i'm using struts

I apologize for my English

+2  A: 

Well the first question I have to ask is: if this is a J2EE application, what are you doing manually loading JDBC drivers? This is what data sources are for.

Secondly, if you do need to dot his then ask yourself this: what is the result of this exception happening? Is it recoverable? Or is the failure so catastrophic your application can't run?

If it's so catastrophic your application can't run do this:

try {
  ...
} catch (SomeCheckedException e) {
  throw new RuntimeException(e);
}

There is no point polluting your interfaces with "throws ..." clauses.

Alternatively if it is recoverable or potentially recoverable then you do need to handle it more nicely. It's hard to give an answer as to how though. Really it depends on the circumstances.

For example, if you're loading modules/plugins this way, you just log that plugin XYZ could not be loaded (logging the exception) and move on. If this is the direct result of a user action you need to somehow report to the user that the action failed (and also log the error), etc.

cletus
+1  A: 

Exception handling is always a question of "Can i handle it?" - where handle means more than log and rethrow.

Sometimes it is worth to catch just to throw an exception of an other abstraction level ("Can i produce a more clear error for the caller?").

In both cases you have to think about passing the cause or not ("Has it useful informaton for the caller?") - not just do it any time, you will get tons of useless log files. When catching an exception, you would normally log the catched exception, maybe with debug level only, but in case of debugging a customers system, good log information is often the only chance to "debug" the system.

Exception handling and logging is often not done well. But for a product or longtime project it would be a good investment.

Arne Burmeister