Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: InterruptedIOException and Max book

 
Terry Martinson
Ranch Hand
Posts: 293
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Max's DVDDbAdapter class has methods that throw the InterruptedIOException to indicate a threading error occurred.
On p. 115 in Max book, Blocking on I/O section - 2nd paragraph, I am understanding it to mean that this interruption stuff is only done if your I/O is done via a channel in J2SE 1.4.
I am using 1.4, but not using channels - I just use RandomAccessFile.
Am I correct in assuming I don't need to include this InterruptedIOException?
TJ
 
Nicholas Cheung
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Terry,
In my implementation, I play quite safe that, I will declare the try-catch block to catch any possible exceptions, like IOException, FileNotFoundException, etc, but I have also catched the unknown exceptions.
For example,

Do you think it is a better approach?
Nick.
[ January 06, 2004: Message edited by: Nicholas Cheung ]
 
Terry Martinson
Ranch Hand
Posts: 293
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's a good question. I would probably prefer to be safe like you. However, are we going to lose marks for not knowing exactly which exceptions to catch?
Anyone else out there have thoughts on :
1. the original posting related to the interrupted exception
2. having a final catch of Exception to make sure we catch anything we are not aware of
Thanks.
TJ
 
Javini Javono
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Terry Martinson:
That's a good question. I would probably prefer to be safe like you. However, are we going to lose marks for not knowing exactly which exceptions to catch?
Anyone else out there have thoughts on :
1. the original posting related to the interrupted exception
2. having a final catch of Exception to make sure we catch anything we are not aware of
Thanks.
TJ

Hi,
concerning item 2 in the above quote.
Having been reading up on Exception handling at Sun's tutorial site,
and speaking in general and not addressing the specific context
of this particular thread,
if an I/O operation (or any operation) occurs and it could potentially
throw an Exception of any kind, then somewhere, at some level in your
hierarchy of invocation, it's hard to imagine you not wanting to deal
with it. The interesting question is where, and then how.
I've been using the compiler to tell me which checked exceptions
I need to handle (or decide to allow to percolate up to invoking
methods).
For run-time exceptions, these automatically percolate up the system.
And, at some point, particularly for run-time exceptions, I suspect
that I will have a catch block which catches Exception, otherwise
my program will crash, and this certainly is not acceptable, even
if I don't know at compile time what this unchecked exception will
be (of course, after testing, one can only hope that there are
no unchecked exceptions thrown, but there are no guarantees).
thanks,
Javini Javono
 
Xie Ruchang
Ranch Hand
Posts: 160
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

And, at some point, particularly for run-time exceptions, I suspect
that I will have a catch block which catches Exception, otherwise
my program will crash, and this certainly is not acceptable, even
if I don't know at compile time what this unchecked exception will
be (of course, after testing, one can only hope that there are
no unchecked exceptions thrown, but there are no guarantees).

The Program will not crash even if the runtime exception is not caught. It will just display the printstack on the console. I think this is better that catching Exception and do nothing about it. It is better in real life to have the message printed than to have the program run abnormally but giving the impression that it is correct.
For every method call, the developer should be aware of the runtime exception it will raise. For example, NumberFormatException of Integer.parseInt("abc"). It is therefore the developer responsibility to expect these exceptions and to catch them specially. Other common runtime exception are NullPointerException and IndexOutOfBoundsException which are really raised by the system due to the carelessness of the programmer.
As a developer, I would rather the system crash than to behave abnormally or incorrectly without my knowledge. My 2cents worth.
 
Javini Javono
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Good points. I'll do a test to see if the program
will abort; but, now that I think about, I sometimes
think I have seen weird messages from the internals
of Java's Swing, which probably were run-time errors,
and these did not crash the program.
Concerning hiding exceptions: this was not my intention.
Concerning the console output: this is may be quite fine
given that we know in advance the application will be run
from the command line. In fact, it may be desirable since
it would be hard to convert the run-time message into English.
Thanks,
Javini Javono
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Guys,
Not sure I understand the question. Can you break it down a bit?
M
 
Javini Javono
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

The Program will not crash even if the runtime exception is not caught. It will just display the printstack on the console.

Hi,
Here's a small test I ran to purposefully create a run-time exception:

And the result was that the program "crashed"; that is,
it ceased to execute the System.out.println statement thus:


> javac suncertify/*.java
Process javac.EXE exited with code 0
> java suncertify/SmallTest01
java.lang.NullPointerException
at suncertify.SmallTest01.main(SmallTest01.java:16)
Exception in thread "main"
Process java.EXE exited with code 1

Given this test, and please remember that I am currently learning
about exceptions myself, I'd recommend that somewhere in the
hierarchy, that all exceptions be caught to stop the programming
from crashing; and, any caught exceptions should be reported
in some fashion. i.e.

But, I'm still a greenhorn, regardless of what the system
calls me.
Thanks,
Javini Javono
 
Xie Ruchang
Ranch Hand
Posts: 160
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

If you try the above program, it did not "crashed" or put it in a proper term "terminated".
Your program terminate because the main thread ends. That is normal. If there is not exception, your program will end or terminate anyway. If you try the above program, the exception will NOT terminate the program. There is still the Swing thread running and therefore the program continues.
Hope this helps a bit and not throw in some confusion.
 
Terry Martinson
Ranch Hand
Posts: 293
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Question for Max - I hope you're still out here. You had asked for a breakdown of the questions, so here goes:
From the original post:

Max's DVDDbAdapter class has methods that throw the InterruptedIOException to indicate a threading error occurred.
On p. 115 in Max book, Blocking on I/O section - 2nd paragraph, I am understanding it to mean that this interruption stuff is only done if your I/O is done via a channel in J2SE 1.4.
I am using 1.4, but not using channels - I just use RandomAccessFile.
Am I correct in assuming I don't need to include this InterruptedIOException?

1. Is assumption above correct?
2. Is it considered a good practice to end a try-catch block with a catch of the general Exception "to be safe", or will we lose marks for this since Sun may expect us to know each and every exception that may be thrown in our application?
Thanks.
TJ
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi TJ,
Originally posted by Terry Martinson:
Question for Max - I hope you're still out here. You had asked for a breakdown of the questions, so here goes:
From the original post:

1. Is assumption above correct?

Yes, it's correct. It's a useful exception, and you may choose to throw it, but it's not required.

2. Is it considered a good practice to end a try-catch block with a catch of the general Exception "to be safe", or will we lose marks for this since Sun may expect us to know each and every exception that may be thrown in our application?
Thanks.
TJ

It seems unconventional to me. An alternate way of achieving the same result would be for your wrapper to catch Exceptions, and throw, say, a FatalErrorException to the middle tier. The middle tier could then, say, log a severe message and gracefully shut down the server.
M
 
Terry Martinson
Ranch Hand
Posts: 293
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Max.
TJ
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No problem, happy to help. If you're really interested in the InterruptedIOException, read on.
Back in the old days(pre jkd 1.4), it was possible for a thread which was doing IO to get some sort of IO Exception( or even other things), yet never die. Thus, it( the Thread) would simply hang around, refuse to die, and refuse to release the File. This was Very Bad, and there's an excellent discussion about it in Taming Java Threads.
In JDK 1.4, they decided to fix this issue, but they had a problem. What, exactly, was the nature of the error? Was it IO? Was it Threading? They decided it was both, and thus used InterruptedIOException. It extends from IOException, yet it's clearly implicated with Interrupts( and thus Threads). And now you know the rest of the story.
All best,
M
 
Chris Harris
Ranch Hand
Posts: 231
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
HI,
My method within my CSRAdpater (which is similar to Max's DVDDbAdapter) throw IOException instead of InterruptedIOException and IOException.
I have done this as InterruptedIOException is a subclass of IOException. Therefore if InterruptedIOException is thrown within my DB code it would be managed when I catch the IOException.
I have decided to use the new IO channels to read the database. Can you confirm that by just throwing IOException I don't have to worry about the InterruptedIOException. I was convinced I was right (well I was before I read this topic ).
I feel that it is better to ask now (even if it is a stupid question) then fail.
I terms of catching general Exception, this is something I have only done with my GUI Controller. This aim of this is to manage the Exception by displaying a user friendly message to the user. This is a every much like the way as Max has suggested.

Chris.
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Chris,
Can you confirm that by just throwing IOException I don't have to worry about the InterruptedIOException.
If I understand how you're doing this, then I agree with you: you're ok. However, it's easy enough to check: they're both checked exceptions, so your code should fail to compile if you're doing it incorrectly.
All best,
M
 
Chris Harris
Ranch Hand
Posts: 231
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Max.
 
Ulrich Heeger
Ranch Hand
Posts: 266
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi everyone, hi Max,
I will benefit of this thread to ask you, Max, a question concerning the catching of general exception. Because at one point I have a concrete problem if I should use a general Exception catch-brace.
Like I have mentioned in a prior thread I have copied your idea of implementing a new Thread to notify repeatingly my WeakHashMap to avoid dead lock. I'm free to post the code once more:

Phil suggested to catch only the InterruptedException but now after reading this thread I'm a little bit unsure if I shouldn't keep this general catching brace. Because beside the Int.Exception also a RuntimeException might occur(?) and thus this thread might die contrairly to the rest of the application.
Comments?
Thanks in advance,
Ulrich
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ulrich,
Good catch ! You're right I think but I'll go on with this in the initial thread.
Regards,
Phil.
 
Stephen Galbraith
Ranch Hand
Posts: 90
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,
It alway's scares the heck out of me when I see a generic Exception being caught as a rule.
I hate it! It would seem that it makes it very easy to start breaking things if I need at some future time, to "update" my code and introduce a new exception. If you have the "catch all" approach, then when you compile you don't get warned about the "new" exception you are throwing, as it's already caught by the high level one (am I making any sense?).
I do appreciate that there are times when you want to do this (maybe at the top level so the program doesn't fall over and leave everything in a mess), but I think it should be avoided in general.
Anyway, happy 2004 to you all!
Regards,
Steve
 
Xie Ruchang
Ranch Hand
Posts: 160
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi folks
An excellent article on
Best Practices for Exception Handling
Best Regards
 
Chris Harris
Ranch Hand
Posts: 231
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Interesting article Frakie.
However point 3 :
3. Try not to create new custom exceptions if they do not have useful information for client code.

Is that not want Sun have asked in the assignment as they want Exception to be created like RecordNotFoundException, SecurityException etc.
I personally disagree with this point. As it helps developer understand what has gone wrong with out having to read the Exception message. For example a FieldNotFoundException tells the developer that the field at they where looking for could not be found. The developer could then do something like use default values. If you just create a new Exception("Field not found") it may not be appropriate for the developer to just restore default value as the Exception could be caused by any subclass of Exception.
I have seen some code that logs message to a log file for within the actually exception. I can see the advantage that you know that the exception will always be logged. But also the disadvantage in the fact the caller of the method is not in control of the logging. What do people thin k of self logging exceptions?
Chris.
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Chris,
I also disagree with Gunjan's recommendation "Try not to create new custom exceptions if they do not have useful information for client code". He makes the comment that if you are not adding information, then you should just throw Exception. But then he goes on later to say "Do not catch top-level exceptions". This contradicts his suggestion to throw Exception (and is the main reason why I would recommend against ever throwing Exception).
I have seen some code that logs message to a log file for within the actually exception. I can see the advantage that you know that the exception will always be logged. But also the disadvantage in the fact the caller of the method is not in control of the logging. What do people thin k of self logging exceptions?

I prefer to use the standard Logger.log() method with it's inbuilt exception logging capability. That way you can explicitly log the exception at the time you feel it is appropriate.
Regards, Andrew
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic