• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Programmatically or JVM thrown Exception?

 
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Why NullPointerException is JVM thrown and NumberFormatException programmatically thrown?
 
Bartender
Posts: 10336
Hibernate Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Not sure I follow what you mean. What do you mean by "JVM thrown"?
 
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
JVM thrown Exceptions are also known as "unchecked Exceptions" while those which have to be programmatically handled are also called "checked Exceptions".
The first ones rise when something unexpected or that you don't know(want) to handle happens. The second ones are thrown when something wrong, but that you was in some way aware of, happens.

Now, NULL is a perfectly legal and meaningfull value. You can write perfectly correct code which deals with it. Often you even DESIRE to be able to receive null values. Java designers decided to let the single coder to choose how to deal with such problems. Moreover, but it's my own opinion...what would you think about reading at the code of a big proejct where you have to always use a try-catch block to simply handle methods parameters? it would be boring, wouldn't it? Better to live the single consider dangerous cases. Especially because he would usually know what to do.

What about a String containing a malformed/illegal number? What could an API class do receiving such a bad parameters? It cannot return NULL...it wouldn't be correct. Nor it could return a FALSE boolean value..'cause Java only allows a return value (maybe a Collection, but it always a reference to a single object). The method doesn't simply know what to do and it has no other way to communicate the application about the wrong situation...Therefore, an Exception. Checked 'cause we, programmers, already know it could happen and have no other way to prevent it.

This is my post here and English not my mother tongue...hope I have been enough clear.



PS: Thanks to Kathy and Bert for their wonderfull book. Thanks to it, it took me about 4 months in my free time (about 100 hours I think) to get the SCJP. But, most of all, it allowed me to greatly improve in my job...(got 3 carriers advancement in a couple months...and I just work since a year). Really thank you fellows, you rock
 
Ranch Hand
Posts: 2308
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Runtime exceptions are something which are very fatal and there are absolutely no change for recovery (Like NPE).

Whereas Checked exceptions are exceptions that has to be caught as there might be scenarios from which you can continue with the flow of the program even after getting an exception.

For NumberFormatException you can set some default value to the variable in the catch block.
 
Paul Sturrock
Bartender
Posts: 10336
Hibernate Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


JVM thrown Exceptions are also known as "unchecked Exceptions"


You know, in all the years I've been writing Java/reading about Java I've never heard unchecked exceptions described as JVM exceptions. Thank you Bianchi Francesco for explaining that.

I'm still not sure I understand what Akbar Khan is asking though. Both NullPointerException and NumberFormatException are unchecked exceptions. Are you asking why the writers of Java deliberately wrote mehtods like Integer.parseInt(String str) to throw a RuntimeException rather than a checked exception?
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'll have to think longer about "JVM exceptoins are unchecked" but I'm sure you can't say the converse: "unchecked exceptions are JVM exceptions" is not true. I make my own and throw and catch em all the time.

If null pointer was a checked exception you'd have to wrap almost every method call in a try-catch block. It's A Good Thing that what you've called "JVM exceptions" (still thinking on those) are unchecked!
 
Francesco Bianchi
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Stan James:
I'll have to think longer about "JVM exceptoins are unchecked" but I'm sure you can't say the converse: "unchecked exceptions are JVM exceptions" is not true. I make my own and throw and catch em all the time.



Can't get the meaning of making your own unchecked Exception and then catching them.. Why not to directly go with checked ones if you think to put them in a try/catch block? Isn't this a little like a "dangerous obfuscating" solution? Or did I misunderstood whay you wanted to say?

Anyway, sorry guys for being unexact. No, definetely unchecked Exc. are by no means exclusively JVM thrown ones.

Anyway.. I think much more can be said about the difference of an Exc like NullPointer and NumberFormat but it would be a long speech.. (and mostly made up of speculations). Here some of my thoughts: I think much has to do with the fact that NullPointer are in a certain way bound to heap management (therefore with JVM native code), are somehow "structural critical exceptions" which cannot be easily foreseen by "java" code. Moreover it's maybe the most common and widespread Excep. in the Java platform. NumberFormatException, on the other side, is a very localized one, tipycally not a critical one and can be by far foreseen during the "number parsing" algorithm.
 
Author and all-around good cowpoke
Posts: 13078
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Please note that the distinction between checked and unchecked exceptions is only something that the Java compiler observes. There is NO DIFFERENCE at runtime in the way these are handled.

It is very important for beginning Java programmers to keep in mind the difference between compile time errors and runtime events.

Bill
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Can't get the meaning of making your own unchecked Exception and then catching them.. Why not to directly go with checked ones if you think to put them in a try/catch block? Isn't this a little like a "dangerous obfuscating" solution? Or did I misunderstood what you wanted to say?



There is a school of thought that checked exceptions were not such a great idea to start with. After all, many other languages get along fine without them. Some people use unchecked exceptions when they can. I've tried it in a couple systems where it happened to work out quite nicely but I haven't tried to convert my overall style to unchecked exceptions.
 
Francesco Bianchi
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Stan James:


There is a school of thought that checked exceptions were not such a great idea to start with. After all, many other languages get along fine without them. Some people use unchecked exceptions when they can. I've tried it in a couple systems where it happened to work out quite nicely but I haven't tried to convert my overall style to unchecked exceptions.



Thanks Stan. Probably you are right but, at least in my opinion, such a choice goes along with a very well designed architecture. Probably the better context for such a solution to be really effective (and not only obfuscatin) is when you have a chain of methods which doesn't want to handle the Exception but to forward it to higher levels of the application. But, as i said, I think this is a solution only very skilled people should adopt. And if got right the Java spirit, they are making lots of efforts to make also programs written by newbies very tough and reliable. (just think about the introduction of generics in collections...was there any REAL need for apps written by expert people?).
And you are true..after all there are programs which get along very well without excpetion. But also without a compile-time type check... But I think there is a reason if you are programming in Java and not in php

Cheers,
Francesco.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic