Win a copy of Learn Spring Security (video course) this week in the Spring forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Null Pointer exception

 
Mohamed Farouk
Ranch Hand
Posts: 249
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Friends
I have a problem with the code which i am debugging.
It is coded in the sytle as below.

try{
}catch(AppSystemException systemException){
}catch (Throwable t) {
}
Now a Null Pointer Exception has been caught by the Throwable catch rather
than the AppSystemException catch.

AppSystemException extends java.lang.RuntimeException ..

Any reasons you can think of..

Regards
Farouk
 
Stuart Gray
Ranch Hand
Posts: 410
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, this is correct behaviour. NullPointerException is not an AppSystemException. Remember, when you catch an exception you are only catching that class, and any of its subclasses. Just because AppSystemException and NullPointerException have the same parent (RuntimeException), it doesn't mean they will both be caught.

Note that catching RuntimeException is a bad idea (same for catching Throwable).
 
Sripathi Krishnamurthy
Ranch Hand
Posts: 232
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Stuart Gray:
Yes, this is correct behaviour. NullPointerException is not an AppSystemException. Remember, when you catch an exception you are only catching that class, and any of its subclasses. Just because AppSystemException and NullPointerException have the same parent (RuntimeException), it doesn't mean they will both be caught.

Note that catching RuntimeException is a bad idea (same for catching Throwable).



According to the book,
The Java(TM) Developers Almanac 1.4, Volume 1 by Patrick Chan

"There are several scenarios where it is good practice to catch Throwable. For example, in a server application, the threads that handle requests should catch Throwable and relay any errors or exceptions to the client. Another scenario is a long-running thread that performs some background activity. Such threads should catch Throwable, log any errors or exceptions, and then continue functioning.

It is rarely good practice for a method in a library to catch Throwable. In general, errors and exceptions should not be masked from the caller. "

So as per my understanding, if a component is being developed, all the errors/exceptions have to be properly exposed to the user.Hence masking of exception (directly catching theough Throwable) should not be done.
 
Stuart Gray
Ranch Hand
Posts: 410
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thats interesting. My understanding was that catching Throwable was bad because it catches everything - including Errors which are potentially uncoverable. For example catching an OutOfMemoryError could certainly obscure debugging, particularly since the nature of the error may mean that it cannot even be logged anywhere.
 
Tony Morris
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
An OutOfMemoryError is recoverable and should never have been an Error (the debate about the validity of Java exception handling aside).

Consider the following:
You start a VM with 256MB heap, and during operation it averages about 80-100MB heap, until it gets to one certain piece of resource intensive code that attempts to allocate 200MB, which of course, results in a OOME. What do you do? Shut down and die? What if you wish to recover?

I'm going to bet my leftie that the original authors of java.lang.OutOfMemoryError also don't handle the case of a failed malloc/new in C/C++.
 
Ken Blair
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Tony Morris:
Consider the following:
You start a VM with 256MB heap, and during operation it averages about 80-100MB heap, until it gets to one certain piece of resource intensive code that attempts to allocate 200MB, which of course, results in a OOME. What do you do? Shut down and die? What if you wish to recover?


What happens if you have 80-100MB on the heap with a 256MB heap and try to allocate 200MB when 70-80MB of what's on the heap is eligible for collection?
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic