• Post Reply Bookmark Topic Watch Topic
  • New Topic

THROWS is throwing me for a loop  RSS feed

 
Doug Nichols
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I come from a C/C++ background, so I'm accustomed to creating functions with bools for return values... so what's the benefit of wrapping class functions with THROWS Exception rather than just handling the errors in a try/catch block?

At work, I see a lot of code like this:



So why not...



Is there a benefit that I'm not seeing by throwing exceptions up the chain? Seems you can only throw ONE type of exception up, which is the same as me returning a FALSE instead.

thanks!
[ January 18, 2006: Message edited by: Doug Nichols ]
 
Nick George
Ranch Hand
Posts: 815
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I guess false only tells you one thing- it failed. If you send up an exception, you know exactly why and where it failed.
 
Christophe Verré
Sheriff
Posts: 14691
16
Eclipse IDE Ubuntu VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to OOP.

A method 'A' calling a method 'B' calling a method 'C' calling a method 'D' calling a method 'E' calling a...

Imagine that the error occurs at the bottom. Using a boolean, you'll have to return false for ALL methods. Would this be good design ? In the 70s maybe
Instead, if you throw an exception, you'll just have to catch it at the top.
 
Dave Tuttle
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Also, you can throw as many exception types as you want, or a base exception which allows all its subclasses.
You can also use unchecked exceptions, which don't have to be declared anywhere.
--Dave
 
Tony Morris
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Doug,
You are right - there is no tangible criteria for discerning between 'when to use an exception or when to use a return value'. The issue is a result of various literature which uses terms such as "exceptional condition", "unrecoverable error" or "unforeseen developer mistake" - all of which cannot be formally defined.

If you view exceptions merely as contractual signalling in that the method that was invoked is unable to return a type successfully, then it quickly becomes apparant that there are a few problems with Java exceptions. One of which is the implicit unrolling of the call stack.

Imagine the following simple example:

One could read that contract loosely as "the method will return an int, unless it can't, in which case, it will signal to the caller accordingly". The issue now is that the call stack has unrolled and the caller is unable to act in a way to recover. It is also problematic that exceptions in Java are defined as classes, since quite clearly, they are merely metadata on a contract, and nothing more - as opposed to the definition of a class.

You will find much literature that attempts to explain the merits or otherwise of Java exceptions, and in particular the "checked exception versus unchecked exception" debate, which started a few years ago and is unresolved. As far as I am concerned, it will remain forever unresolved until someone points out that the debate rests on a flawed premise. I can only suggest that you do not buy into what this literature says (or what anyone says including myself) without thinking for yourself.

I hope this helps.
 
Layne Lund
Ranch Hand
Posts: 3061
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One reason to use exceptions is if you need to return a value. Java does not have pass by reference to facilitate "returning" multiple values like is commonly used in C/C++. A common idiom in C/C++ is to assign unused values to represent error conditions. For example, i/o functions often return -1 to represent EOF since valid characters are always positive values. However, what if you write a function that can potentially return any possible value that can be stored in the return type? For example, a function that returns int and can return negative values as well as positive ones. In such a situation, exceptions are a helpful mechanism to get around this problem. Exceptions are available in C++, although they still aren't commonly used from my experience.

Layne
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!