Results 1 to 9 of 9
  1. #1
    jurka is offline Member
    Join Date
    Jul 2008
    Posts
    67
    Rep Power
    0

    Default Exception handling and logging

    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.
    Java Code:
            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 ?

  2. #2
    Eranga's Avatar
    Eranga is offline Moderator
    Join Date
    Jul 2007
    Location
    Colombo, Sri Lanka
    Posts
    11,372
    Blog Entries
    1
    Rep Power
    19

    Default

    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.
    Last edited by Eranga; 08-31-2008 at 09:32 AM.

  3. #3
    Join Date
    Aug 2008
    Location
    Saint-Petersburg, Russia
    Posts
    66
    Rep Power
    0

    Default

    Quote Originally Posted by jurka View Post
    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:

    Java Code:
            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:
    Java Code:
    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.
    Last edited by ProjectKaiser; 08-31-2008 at 11:47 AM.

  4. #4
    Join Date
    Aug 2008
    Location
    Saint-Petersburg, Russia
    Posts
    66
    Rep Power
    0

    Default

    Quote Originally Posted by jurka View Post
    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:
    Java Code:
    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:

    Java Code:
    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.
    Last edited by ProjectKaiser; 08-31-2008 at 11:46 AM.

  5. #5
    jurka is offline Member
    Join Date
    Jul 2008
    Posts
    67
    Rep Power
    0

    Default

    ProjectKaiser thank you for long post, but yes i wanted to talk about this example
    Java Code:
            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.

  6. #6
    Join Date
    Aug 2008
    Location
    Saint-Petersburg, Russia
    Posts
    66
    Rep Power
    0

    Default

    Quote Originally Posted by jurka View Post
    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.
    Last edited by ProjectKaiser; 09-01-2008 at 04:46 PM.

  7. #7
    jurka is offline Member
    Join Date
    Jul 2008
    Posts
    67
    Rep Power
    0

    Default

    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!

  8. #8
    Join Date
    Aug 2008
    Location
    Saint-Petersburg, Russia
    Posts
    66
    Rep Power
    0

    Default

    Quote Originally Posted by jurka View Post
    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.

  9. #9
    Nicholas Jordan's Avatar
    Nicholas Jordan is offline Senior Member
    Join Date
    Jun 2008
    Location
    Southwest
    Posts
    1,018
    Rep Power
    7

    Post except if the exception is an exceptional exception...

    Quote Originally Posted by ProjectKaiser View Post
    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.
    Introduction to Programming Using Java.
    Cybercartography: A new theoretical construct proposed by D.R. Fraser Taylor

Similar Threads

  1. JAXP exception handling
    By jovenky in forum Advanced Java
    Replies: 0
    Last Post: 05-27-2008, 01:37 PM
  2. Exception Handling...
    By focus_nitin in forum New To Java
    Replies: 1
    Last Post: 02-16-2008, 03:13 AM
  3. JDBC - Exception handling
    By Java Tip in forum Java Tip
    Replies: 0
    Last Post: 12-05-2007, 04:00 PM
  4. Jstl Exception Handling
    By vamsidharpoosarla in forum JavaServer Pages (JSP) and JSTL
    Replies: 2
    Last Post: 07-18-2007, 06:17 AM
  5. JSTL Exception Handling
    By chaatf in forum JavaServer Pages (JSP) and JSTL
    Replies: 1
    Last Post: 07-18-2007, 02:24 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •