• 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

Using Assertions Appropriately - page 392 of SCJP6 K&B book

 
Ranch Hand
Posts: 50
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
On page 392 of the SCJP6 book
# ISBN-10: 0071591060
# ISBN-13: 978-0071591065

it says "To discourage you from trying to substitute an assertion for an exception,
the AssertionError doesn't provide access to the object that generated it."

What does the above statement mean? Do any other java.lang.Error objects
provide access to objects that generate those errors?

Here's what I tried:



When the above was run , it produced this output with assertions enabled.



I am just trying to find out if there are any other java.lang.Error (subclass) objects that provide access to objects that generate them,
so that I can understand what the above statement from the book means.

http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html
 
Ranch Hand
Posts: 357
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am not sure of these answer,

each Throwable object has a method named getCause(); its purpose as shown in the java docs is:

Returns the cause of this throwable or null if the cause is nonexistent or unknown. (The cause is the throwable that caused this throwable to get thrown.)

and if you call this method on your AssertionError you get a null value.

again i am not sure but i think this is the explanation ;). but as an advice never try to catch the assertion errors they are there only for testing and should be disabled when moving your applications in production.

(peace)
 
Rashmi Jaik
Ranch Hand
Posts: 50
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Omar, thank you for your reply.

I tried to invoke the getCause() method ( on a different java.lang.Error object ) StackOverflowError object (by generating a stack overflow condition that resulted in this error being thrown) , however the getCause() method also returned null in this case.

So, may be the statement

the AssertionError doesn't provide access to the object that generated it

made about AssertionError means something different.



Fine print:
I have read in the K&B book that it is not a good idea to catch java.lang.Errors, but I just tried the above to see if getCause() method does not return null for a different Error (StackOverflowError) other than AssertionError.



 
Ranch Hand
Posts: 1032
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think the key is in the constructors, and in what Omar said about getCause(). Look at the constructors for Error, for example. There is a constructor that is
Error(Throwable t)
Whereas the best you can do with AssertionError is:
AssertionError(Object o)
There is no constructor of the form AssertionError(Throwable t) which is what would set the cause in the AssertionError instance.
 
Rashmi Jaik
Ranch Hand
Posts: 50
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you for your reply Ruben,

This statement " the AssertionError doesn't provide access to the object that generated it"
is referring to the actual object that generated the AssertionError.

Throwable does not generate the AssertionError ever. The only object that is throwing the AssertionError is the object that is an instance of UsingAssertions (in the code above).

What getCause returns is just a Throwable object, it never returns the object that is generating the AssertionError (which is the instance of UsingAssertions class).

Ruben Soto wrote:I think the key is in the constructors, and in what Omar said about getCause(). Look at the constructors for Error, for example. There is a constructor that is
Error(Throwable t)
Whereas the best you can do with AssertionError is:
AssertionError(Object o)
There is no constructor of the form AssertionError(Throwable t) which is what would set the cause in the AssertionError instance.

 
Ruben Soto
Ranch Hand
Posts: 1032
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Rashmi,

I might be wrong, but I think that what is returned by getCause() is actually the original exception or error thrown in your code.
When you do something like:
throw new SomeException();
The object that is the cause of the exception is the instance of SomeException, not the instance object that has the code that throws that exception. But you can actually add that information to the SomeException object on creation, if you have a suitable constructor. You could do something like:
throw new SomeException(this);
Assuming you have the constructor
SomeException(Object o);
Then, what I think happens, is that when the exception is propagated down the call stack, new objects of type SomeException are created, and the way they must be created is with a constructor. So my theory is that because AssertionError is missing a constructor of the type
AssertionError(Throwable t)
That means that you won't be able to retrieve the ultimate cause. You are limited to using something like:
AssertionError(Object o)
But this is just a theory, I'm not completely sure how this works. Maybe someone else can respond.
 
Rashmi Jaik
Ranch Hand
Posts: 50
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Ruben, may be you are right.

I never thought about the possibility.
 
Ruben Soto
Ranch Hand
Posts: 1032
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Neither had I Rashmi That's why asking and answering questions is equally beneficial. But we might be better getting confirmation from other people. Come on, people. Let's start the discussion...
 
Ranch Hand
Posts: 324
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
AssertionError does not allow you to pass the cause of the error. If you look at the constructors, there only allow you to pass a message.

Why doesn't an AssertionError allow access to the object that generated it?
 
Himalay Majumdar
Ranch Hand
Posts: 324
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In Error..we have.

Error(String message, Throwable cause)
Constructs a new error with the specified detail message and cause.

Error(Throwable cause)
Constructs a new error with the specified cause and a detail message of (cause==null ? null : cause.toString()) (which typically contains the class and detail message of cause).


There is no constructor like above in AssertionError..only messages..for your loved ones.

cheers
 
Rashmi Jaik
Ranch Hand
Posts: 50
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Himalay, that makes sense.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic