Throw and System.out.println ?

[Pieter Jacobs]

Hi guys,

1- When will you really use "throw" (an exception), and when "System.out.println" (whether to print the stacktrace or whatever) ?

example:
2- When using "Properties", you use a FileInputStream which is declared within a "try / catch" block; do I use "throw" in this case (within the "catch" block) meaning that the app should terminate because it can not continue if it does not get the value from the properties file ?

It was difficult to put this into words; I hope it makes sense!

Cheers,
Pieter

[Jeroen Kema]

Pieter Jacobs wrote:Hi guys,

1- When will you really use "throw" (an exception), and when "System.out.println" (whether to print the stacktrace or whatever) ?

example:
2- When using "Properties", you use a FileInputStream which is declared within a "try / catch" block; do I use "throw" in this case (within the "catch" block) meaning that the app should terminate because it can not continue if it does not get the value from the properties file ?

It was difficult to put this into words; I hope it makes sense!

Cheers,
Pieter

Hi Pieter,

Have a look at this: http://www.oracle.com/technology/pub/articles/dev2arch/2006/11/effective-exceptions.html

It explains when to use checked and unchecked exceptions and what to do with it. If you're implementing the exeption handling as in the article, you can catch the IOException when reading the properties, and throw an unchecked excpetion from there, because you said you cannot recover the exception from there. A fault barrier, which will probably exists within your user interface layer, should catch these unchecked exception and pass the message to a nice error dialog which explains why the application can't run further anymore.

System.out.println is something that should be avoided as much as possible. When you want some debug output, you should use java logging. You can restrict the logging level when the application is going into production. You don't want to have system.out.println in you production environment, do you?

Regards,
Jeroen

[Pieter Jacobs]

Hi Jeroen,

Thanks for the feedback; I am currently working through everything I can lay my hands on regarding Exceptions and it is actually simple; but as I wrote to Roel just now; I actually got myself so worked up after reading through loads and loads of Topics on Friday night, that I started to feel quite intimidated by some of the guys' code snippets.

Enjoy the evening and speak to you soon.
Cheers.
Pieter

[Ehsan Rahman]

Thanks for the link Jeroen - it led to googling more on exception architecture & antipatterns etc.

[Fernando Franzini]

Hi folks
Using this post.....my questions is:
If I decided in my assignment dont use Logging !!! .....What should I do when catch some exception that I dont pass way ? I mean,...in some cases it dont make sense throw exception to callers....
So

[Roel De Nijs]

Fernando Franzini wrote:What should I do when catch some exception that I dont pass way ? I mean,...in some cases it dont make sense throw exception to callers...

Give an example, because I can't think of one. In my assignment I have some checked exceptions which I catch in my GUI (and show a message for the user) and also a bunch of runtime exceptions, which aren't catch because it's due to a developer fault (not a user one, e.g. my create-method is expecting a not-null array, so if a null array is passed, runtime exception is thrown).

Kind regards,
Roel

[Roberto Perillo]

Howdy, Fernando!

If you are able to recover from the exception, then you do it in the catch block; otherwise, you may choose to throw your exception, or rethrow the exception that was caught. If you are in the latest layer in your architecture (i.e. the GUI), then you may, for instance, call JOptionPane.showMessageDialog, showing an error message. If you are in the services layer, then in most cases, the best thing to do is throw your own exception. The bottom line is, the exception has to be treated when it is time to treat it

[Fernando Franzini]

Hi Roel
Inside my bussines layer....I'm converting String[] to PojoRoom that have apropriates types fieds. One of then is java.util.Date. In this situation I had to try/catch date formating:

try {
    room.setDate(simpleDtFormat.parse(record[5].trim()));
} catch (ParseException e) {
    System.err.println(e.getMessage());
}

This not make sense throw it to View Layer remembering that this exception wont happen...only if database file have some invalid date information...
what do you think ?
Regads

[Roel De Nijs]

Hi Fernando,

That's true! 2 possible options:

just ignore the Date and use a String to hold the date (that's what I did)

throw some kind of runtime exception IllegalStateException("database is corrupted") or something like that

Kind regards,
Roel

[Fernando Franzini]

Hi Roel

I'll

"throw some kind of runtime exception IllegalStateException("database is corrupted")"

Thanks again for the tip !
Regads.

[Pieter Jacobs]

Hi guys,

1- Within the Data class within my read method, is it correct to catch the IOExceptions and throw RecordNotFoundException 's ?

2- Is anyone writing out to a log file ?

Thanks,
Pieter

[Roel De Nijs]

Hi Pieter,

Would throw only a RNFE if you don't find the record. If you have an IOException I would wrap it and throw a custom RuntimeException or for example an IllegalStateException("data in database file corrupted").

I'm using the java.util.logging but not writing to a file, just using the ConsoleHandler. Just used it for debugging purposes, so disabled logging when I submitted my assignment. Because using a file is again adding a complexity that's not needed: where do you put the log file?, what do you do if user doesn't have writing rights for that directory?,...

Kind regards,
Roel

[Pieter Jacobs]

Hi Roel,

Thanks again!!

Enjoy,
Pieter

[Pieter Jacobs]

Hi Roel,

Oh yes, where my question came from:

1- Within the Data class within my read method, is it correct to catch the IOExceptions and throw RecordNotFoundException 's ?

my assignment requires me to implement the DB interface and within the interface the read() method specifies that my method within my Data class should throw a RecordNotFoundException. Do I just add another exception type (e.g. IllegalStateException) to the throws clause?

Thanks!
Pieter

[Roel De Nijs]

Hi Pieter,

My read-method has also the RNFE clause. You just have to require a valid implementation for that method. So no other checked exceptions may be thrown from within that method, but you can throw any runtime exception you want. I created my own runtime exception (DBException), but you can throw an IllegalStateException as well, because your database file has an illegal state at that time (it contains corrupted data).

And you don't have to add runtime exceptions to the method signature, I even think that's considered bad practice. But of course you have to add it in your javadoc. This is my read method signature:

    /**
     * Reads a record.
     * 
     * @param recNo The record number of the record to read.
     * @return An array where each element is a field value.
     * @throws IllegalStateException if this method is called before the DAO is
     *             started
     * @throws RecordNotFoundException if the specified record does not exist or
     *             is marked as deleted
     * @see #startDAO(Object)
     */
    @Override
    String[] read(int recNo) throws RecordNotFoundException;

I used a cache so I don't have the problem you are facing in my read-method. But if you try to read a record before you initialized the data class, you will get an IllegalStateException too.

Kind regards,
Roel

[Pieter Jacobs]

Hi Roel,

Thanks again, I'll first spend some time on exceptions and exception handling before continuing!

Thanks,
Pieter.

[Pieter Jacobs]

Hi Roel (and other guys),

Thanks for all the help so far!

I have gone through tutorials and a book which contains quite a bit regarding Exceptions and would like to specify it here as a summary - and I have a question or so too:

Questions:
- It looks like I had to understand that checked exceptions do not mean that they're checked at compile-time - because RecordNotFoundException will only appear at runtime - is my statement correct ?
- From what I've read, the Exception classes we have to create for the SCJD will extend Exception and not RuntimeException ?
- RuntimeExceptions can be thrown but only if there is a possibility that someone might call the method incorrectly - but then again the code within that method should be able to handle that ?
- Why then (other than the above - and below) will one really throw a RuntimeException (like this IllegalStateException ) - is it not bad practice ?

Summary:
- Only checked exceptions should be added to the throws clause of a method or constructor.
- Only checked exceptions should be caught within a catch block.
- All exceptions are checked exceptions, except if they're indicated as being RuntimeException, Error, or subclasses of these classes.
- RuntimeExceptions and Errors are known as uncheck exceptions.
- Errors should not be thrown or caught.
- RuntimeExceptions should not be thrown or caught either.
- If an app can recover from the exception we should create a checked exception.
- If an app can not recover from the exception we should create an uncheck/runtime exception.

Thanks,
Pieter

[Roel De Nijs]

Hi Pieter,

Seems to me you don't have very much of practical experience with Java based on your questions, but maybe I'm wrong. Like the difference between a checked and a run-time exception is pretty basic stuff and I thought you had to study that for the required SCJP-exam, so I'm a bit wondered to see these questions. But no problem, I'll try to answer them as good as I can.

The exception handling in Java is to my opinion a very powerful feature, but if you don't use it wisely it can become a real problem and make your code be unreadible, not maintainable and so on.

now your questions:
- a checked exception is an exception you have to handle (catch it in a try/catch/finally block or just let it fly and add a throws-clause to the method which is calling the possible exception method). if you don't do it, the compiler will complain with a compiler error. So with a little example, assume: RNFE is a checked exception and your method signature is String[] read(int recNo) throws RNFE;

// possibility 1
void readFirstRecordFromData() {
  try {
    data.read(0);
  } catch (RNFE e) {
    // handle it
  }
}

// possibility 2
void readFirstRecordFromData() throws RNFE {
  data.read(0);
}

// compile error
void readFirstRecordFromData() {
  data.read(0);
}

- I would say yes! I made the exceptions declared in sun's interface all checked exceptions. But there are other opinions about this on this forum.

The last 2 questions I answer together. It is certainly not bad practice to throw these runtime exceptions. it even makes your code more readible, less complicated,... I will show this with a small example. Let's take the update method: as a parameter an array is passed. The array is expected to be same length as number of columns in the database file (also indicated in the javadoc). So at the start of the method I check it (together with another set of validations). If it's not ok i throw an IllegalArgumentException with an appropriate message. In the actual update code I know the complete array is valid and I can just use it without doing extra checks to be able to handle all possible arrays (someone can pass to the method) to not get an ArrayIndexOutOfBoundsException for example. And it gives also a pointer to other developers that have to use my code (without having them to dive into the code if they have sources). If you use my api (through a jar) to develop your own application and you pass an array of length 5 you will get an IAE telling you that array is supposed to be of length 6. I think these runtime exceptions are very valuable to check incoming parameters or the state of an object when calling some method.
And if your application is developed perfectly you'll never will see such a runtime exceptions, so you don't have to provide handling of these type of exceptions.

Kind regards,
Roel

[Pieter Jacobs]

Hi Roel,

Thanks for the reply again.

It's a matter of fact, I did a lot of delphi coding before, as well as Java coding, but I never used the Exceptions classes properly and to the full extend; even a few other things I never used (like swing). I did do the Programmer exam in 2007 and even though I scored very well on Exceptions, it is only when you start applying what you've learned that you start gaining experience with it.

Since I started the SCJD assignment I have learned a tremendous amount - from design patterns, to exceptions, to swing to even uml that I've never knew or looked at before. One of the main things is the fact that I never did a course on Java and never had people guiding me, so most of the stuff I do, I sit and wonder if this is the correct way of doing it and isn't there maybe an easier way

I do appreciate your guys' help and I know there will be more questions I will post here, but I'm really enjoying the learning and the assignment.

Regards and have a great weekend! - at least we have a public holiday here in South Africa on Monday

Pieter