Exception handling and logging

[jurka]

As i have read some of the exception handling articles, how to handle and log them. So the best way is to handle exception at top level. But in some articles i have seen this example of right way handling exceptions and logging.

        try {
           ..................
        } catch (IOException e) {
            log.error("Config file got I/O exception " + e.getMessage());
            throw new RuntimeException();
        }

I get the logging part, but why to re throw RuntimeException? It's not catch able and freezes program ?

[Eranga]

I'm not clear what you are asking about exception logs. If you want to record all exceptions there are lots of ways. Either you can find a solution on the web, like log4java, or you can write your own logs.

In the code you have post here, basically catch any IOException, and specifically throws the runtime exception. In this way you can't catch any IOException, only possible throw specific exception.

Hope it's clear.

[ProjectKaiser]

I get the logging part, but why to re throw RuntimeException? It's not catch able and freezes program ?

We use similar, but improved :) technique:

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

So I throw RuntimeException with original exception as a parameter. It is usefull when exception is printed at the top level - all incident history are show.

Why do I personally do so ? To get rid of annoying exception declaration. If you use sql package your methods have to declare bunch of sql exceptions. I strongly dislike it. We even rewrote usefull sql package classes like Statement:

public class Stmt {

    public boolean execute(String sql) {
    	PSI psi = ApiAlgs.getProfItem(Stmt.class.getName(), sql);
        try {
            return m_statement.execute(sql);
        } catch (Exception e) {
            ApiAlgs.rethrowException(e);
        }
        finally{
        	ApiAlgs.closeProfItem(psi);
        }
        return false;
    }
...
}

Here we added exception rethrowing functionality plus we profile our queries.

I'm not sure why you applied "It's not catch able" words. RuntimeException can be caught like any other exception.

[ProjectKaiser]

But in some articles i have seen this example of right way handling exceptions and logging

Let's discuss now a little bit whether it is "right way" or not.

Handling exceptions are very dangerous - for this you have to write code, and any code must be considered as buggy until proved. So if you handle exceptions many times, you potentially have a lot of bugs. Being purists we'd have to write separate testcase for any piece code which handles exceptions. This is not always appropriate :)

So good rule would be to handle exception once at the top level. But it is not always possible, sometimes because of Java language.

Imagine you are writing logger. You starts with something like this:

public class Logger{
   public void log(String msg){
   };
}

Let your log() method writes to file. In this case you have to deal with io functions and if you do not catch IOException, you will have to change class contract:

public class Logger{
   public void log(String msg) throws IOException{
   };
}

This is not always acceptable. So the only chance for you is to catch IOException, rethrow it as RuntimeException, and write testcase for it.

[jurka]

ProjectKaiser thank you for long post, but yes i wanted to talk about this example

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

Why to rethrow RuntimeException ? It's not catched and i cant get what's this point ? I would log before the exception is being throwed and that would be all.

But yes as you talked here about sql package which needs much exception handling, i got similar package ftpclient where i need to handle exceptions anywhere. Truth is there is about after every 20 lines exception handling, which really ruins my code and makes it hard to read. There are simple exceptions which needs to be handled, like ConnectionClosed, UnknownHost, Unknown request and so on. I havent found good design for that.

[ProjectKaiser]

Why to rethrow RuntimeException ?

Because "normal" execution flow should be terminated in most cases if exception occurs. There are rare cases when it is not true, so I'd avoid them for the moment.

If we do not rethrow then execution continues from some strange point, in most cases this is not desirable.

Again, RuntimeException is caught and thrown mostly to keep class contract intact. Java methods must declare any exception but RuntimeException, this is why not-runtime exception is caught and rethrown as RuntimeException.

I would log before the exception is being throwed and that would be all.

Well, if for some reason you do not want to rethrow exception then do not do it, of course.

I havent found good design for that.

Good design is to rethrow them as RuntimeException :)
If you use some package very intesively it might be worth to make wrapper like we did with sql classes Statement, ResultSet etc.

[jurka]

So here is my understand of throwing another Exception, it's basically meant for stopping program flow, like when you got FileNotFoundException then program can't work further so i kill it by throwing exception which i cant catch.

Yeha for good design i really need to handle exceptions in wrapper.

Also one thing, thank you for discussion!

[ProjectKaiser]

so i kill it by throwing exception which i cant catch.

Why ? There is no single problem with catching RuntimeException.

Yeha for good design i really need to handle exceptions in wrapper.

BTW, I think this is one of the very few Java weaknesses. Forcing methods to have explicit exception enumeration brings more problems then solves.

[Nicholas Jordan]

BTW, I think this is one of the very few Java weaknesses. Forcing methods to have explicit exception enumeration brings more problems then solves.

Ah, the voice of Masters. We seem to be accumulating them.

What gives here ( an exquisitely correct reversal of idiomatic in my culture ) is known Industrial Engineering, and is parodied by the title here. By iterative development, one can bubble the non-exceptional E&O ( errors and omissions ) from the exception chaining, but one cannot program away realities.

Reading just a few of the frames in this thread, I offer that what I have settled to is placing a record of activity in AES-256 protected records and issuing an MD-5 ( Okay, Pat, HMAC ) issuing a hash of the matter to managers, then sign it with a ROT-13 joke.