Doubt in K&B SCJP 6: topic: AssertionError Source

[Morteza Manavi-Parast]

While in the K&B SCJP 6 book on page 382 mentioned that AssertionError is thrown Programmatically, I found this to be thrown by JVM according to other sources. I personally think the source of this Error is JVM since this is the JVM who throw the Error when assertion is enabled and the assert expression is evaluated to false. I checked the javadoc and JLS for assertion error and could not find any explicit statement about whether it thrown by JVM or programmer. So is it a mistake in the book or it really thrown by programmer?

[Marco Reuel Perez]

Here is the way I look at it..

AssertionError is programatically thrown in the sense you are the one who is recommending the JVM to assert certain condition in your program at runtime. Now if you don't put the assert statement the JVM does nothing 'on its own' to assert a condition. So AssertionError is programatically thrown, meaning, you code for that assertion which the JVM makes sure is correct if not throws an error. If you didn't put the assert statement in the first place there is nothing the JVM does on its own to assert and there is no possibility of an AssertionError being thrown at runtime.

Programmatically thrown in the sense not explicitly throwing the error in the program. It means an exception or error caused solely because of your program at runtime.

Hope this helps.

-Reuel.

[Morteza Manavi-Parast]

Programmatically thrown in the sense not explicitly throwing the error in the program. It means an exception or error caused solely because of your program at runtime.

Thanks for the reply, but then I would say all of the exceptions are programmatically thrown. I think in the K&B book they are categorizing the exceptions and errors in the essence of which is thrown by JVM and which is thrown by API developer and so my concern is more about the source of the exception or error being thrown than the reason of it. But whatever, I don’t want to start a debate on this since I’m very close to my exam. So do you think that if I encounter this on my exam, I should mark it as a programmatically thrown error?

[Bert Bates]

Hi Morteza,

Even though you're close to the exam, I think this is worth discussing

I'll start by asking you to describe in your own words what the difference is between programmatically thrown and JVM thrown. I think that once we have a definition that we agree to, you'll be able to answer this question, and any questions you encounter on the real exam.

hth,

Bert

[Ruben Soto]

I raised this question before: AssertionError

And I agree that AssertionError is most commonly thrown by the JVM.

To answer Bert's question: If XyzException is most commonly thrown programmatically, that means that when XyzException instances are thrown it is most often due to a "throw new XyzException();" statement in program code. This is obviously not the case for AssertionError, and so AssertionError is most often thrown by the JVM (the book is incorrect.)

I know what you are probably going to say next: "But you are actually forcing the AssertionError by doing an "assert false;" in your code, so it should be considered a programmatic event. And my answer to this is: I can also throw a NullPointerException by doing "Integer a = null; a.byteValue();' in my code. Does that make NullPointerException programmatic too?

[Morteza Manavi-Parast]

Hi Bert,

Thank you so much for considering this thread. As a matter of fact, Ruben exactly explained what I wanted to say. In my opinion thrown programmatically means “explicitly thrown by the API developer in the code”.

When I looked at your SCJP 1.6 book at the table 5-2 on page 382, I see that you specified NumberFormatException, IllegalStateException or IllegalArgumentException as “Typically Thrown Programmatically” which is absolutely compatible with my opinion, having said that, I think AssertionError cannot be in the same category with those guys.

So, in conclusion, I differentiate an Exception source by “Who throw it” instead of “Who cause it”; since almost always we (Programmers) are the cause of the exceptions and under the hood the JVM or the API developer responds to us by throwing an exception.

However, still I’m very interested to know about your opinion in this regard.

P.S. Thanks Ruben for the nice explanation!

[Bert Bates]

I promise to share my opinion, and with that said I'd really like to hear other opinions first

[rhett howard]

Hey,
You got a point there! But why would you ever wanna throw a null pointer exception expllicitly?
If you do that, I think you can say null pointer exception can also be thrown programmatically.But , i don't think you should do throw a null pointer exception, rite??
Assertion Error can be said to be thrown programmatically 'coz you are forcing the error to happen at a particular point and is basically used for debugging and stuff, rite??

[Bert Bates]

I think Rhett is on the right track.

Does it make sense to think in terms of "programmatic" being situations that the programmer has decided ahead of time she wants to handle?

[Ruben Soto]

I am afraid I don't follow (the whole point of AssertionError is that it should never be handled explicitly by the programmer in the code, but cause the program to fail.) Also, an assert statement doesn't necessarily mean an AssertionError will be thrown. Since we are talking about whether the AssertionError itself is thrown programmatically, I think it is important to make that distinction. With an assert statement, you are not forcing anything (but even if you are, as in the case "assert false'", you can also argue the same for NullPointerException in the example that I gave earlier (try to call toString() on a null reference, for example.)

The main point though is that if you are willing to maintain your position that AssertionError is thrown most often programmatically, then you need to provide a clear textual definition of what throwing an exception (or error) programmatically is. I think the definition that I gave is reasonable, because it requires an explicit throws clause in method code, something that is precise and ascertainable. If you think that definition is not correct though, you should provide an alternate definition. This is supposed to be science, not some sort of black art that requires guessing, mind reading, or transcendental meditation.

[Ruben Soto]

Bert,

Let me know what you think about this definition (I think this is what you meant):

An exception/error is thrown programmatically when some code operation is specifically coded to potentially throw that exception/error. In some cases, the given code operation will always throw the exception/error (as in a throws statement), while in others it might potentially throw it (as in an assert statement.) It is worth noting that the only purpose of the specific code operation under consideration must be to (potentially) throw the exception/error. Therefore, other operations such as an attribute reference (which might for example cause a NullPointer exception when the reference is null) can not be considered to give rise to programmatically thrown exceptions/errors. More specifically, only explicit throw or assert clauses can cause exceptions/errors to be thrown programmatically.

Let me know if that's what you had in mind.

[Ninad Kulkarni]

'coz you are forcing the error to happen at a particular point and is basically used for debugging and stuff, rite??

Hi, All
I think rhett howard is correct. AssertionError is thrown programatically.

[Ryan Slominski]

Bert Bates wrote:I'd really like to hear other opinions

I'm going to have to side with the AssertionError is thrown by the JVM camp. There are two reasons why this makes more sense:

Generally Errors are thrown by the JVM (I don't know of any Error that is appropriate to throw in program code)

It is simpler to define "programmatically" as meaning literally using the "throw" reserved word in program code

Rationalizing AssertionError being thrown programmatically is too much work - you have to first agree to be an exception (no pun intended) to the rule - don't throw an Error. Then you have to agree that the definition of "programmatically" is a developer's premeditated intent, which is much more complex and subjective.

Of course if I get this question on the certification exam I'll know from Table 5-2 of your Study Guide to answer that AssertionError is thrown programmatically!

[dennis deems]

But is it not the case that the following are equivalent?

assert (x > 0);

if (x <= 0) throw new AssertionError();

And we choose to write assert condition because it's simpler and more graceful?

I'm in the programmatic camp. An assertion error can not happen unless a programmer deliberately makes it happen. It's not like a Stack Overflow or an IO Exception.

[Ryan Slominski]

As was already pointed out you can make the same argument with NullPointerException (which is reportedly thrown by the JVM):

String s = null;

if(s == null) throw new NullPointerException();
s.length();

vs

String s = null;
s.length(); // Just let the JVM throw the NullPointerException (it's simpler and more graceful)

The argument for the programmatic camp appears to be that the application developer has a certain amount of control over an AssertionError; In other words the application developer can choose to include AssertionErrors or leave them out (or turn them off at runtime). This characteristic of AssertionError does give it some ground on the thrown programmatically side (perhaps to say it indirectly is thrown by the developer), however, it seems to me that it still fits the thrown by JVM side more easily.

This is an interesting debate since any Throwable can be thrown programmatically. I wonder if making the (apparently subjective) distinction on a certification exam actually has any value, at least as far as AssertionError is concerned?

Dennis Deems wrote:It's not like a Stack Overflow or an Illegal State.

Not sure what you mean; StackOverflowError is an Error thrown by the JVM and IllegalStateException is an Exception thrown programmatically.

[dennis deems]

Ryan Slominski wrote:As was already pointed out you can make the same argument with NullPointerException (which is reportedly thrown by the JVM):

String s = null;

if(s == null) throw new NullPointerException();
s.length();

vs

String s = null;
s.length(); // Just let the JVM throw the NullPointerException (it's simpler and more graceful)

The case isn't analogous at all. You would never write that code in real life -- or at least I hope you wouldn't. There's no reason on earth to perform a null check only to then throw a null pointer exception. Null checks are performed to prevent the exception from being thrown. In real life, NullPointerException is a problem that must be fixed, it is NOT the desired outcome. Assertions aren't anything like that - or at least aren't meant to be. They are a way for the programmer to communicate assumptions about the state of the program.

Ryan Slominski wrote:The argument for the programmatic camp appears to be that the application developer has a certain amount of control over an AssertionError; In other words the application developer can choose to include AssertionErrors or leave them out (or turn them off at runtime).

No, you're missing the point. A NullPointerException will happen any place the code calls a method on a null object, regardless of the programmer's wishes, and whether or not the programmer realizes it is a possible outcome. The programmer can try to anticipate that possibility and prevent it, but it often happens anyway where the programmer did NOT know it might happen, because of bad input or whatnot. An AssertionError only happens where the programmer, with full knowledge, makes it happen. To the best of my knowledge the JVM can never throw an AssertionError that the programmer hasn't put there to be thrown.

[dennis deems]

Ryan Slominski wrote:

Dennis Deems wrote:It's not like a Stack Overflow or an Illegal State.

Not sure what you mean; StackOverflowError is an Error thrown by the JVM and IllegalStateException is an Exception thrown programmatically.

Yeah, my mistake, not sure where my head was. I think I meant to write IOException. :S

[Ryan Slominski]

Dennis Deems wrote:You would never write that code in real life

But isn't your example just as unlikely:

if (x <= 0) throw new AssertionError();  

Dennis Deems wrote:A NullPointerException will happen any place the code calls a method on a null object, regardless of the programmer's wishes

Actually, I think we agree here: a developer has more control over an AssertionError than any other JVM Error. I guess what we still disagree about is whether that means it is being thrown "programmatically".

Another interesting question is whether a RuntimeException or Error should ever be thrown programmatically. It is almost like saying your program just gives up by design (since a RuntimeException or Error generally isn't something you can recover from).

[Tommy Delson]

Morteza Manavi-Parast wrote:While in the K&B SCJP 6 book on page 382 mentioned that AssertionError is thrown Programmatically, I found this to be thrown by JVM according to other sources. I personally think the source of this Error is JVM since this is the JVM who throw the Error when assertion is enabled and the assert expression is evaluated to false. I checked the javadoc and JLS for assertion error and could not find any explicit statement about whether it thrown by JVM or programmer. So is it a mistake in the book or it really thrown by programmer?

Assertion Error is Programmatically and here is why:

Assertions let you test your assumptions during development, but the assertion code basically evaporates when the program is deployed, leaving behind no overhead or debugging code to track down and remove.

Recap from K & B book page 423:
Assertions are typically enabled when an application is being tested and debugged, but disabled when the application is deployed. The assertions are
still in the code, although ignored by the JVM, so if you do have a deployed application that starts misbehaving, you can always choose to enable
assertions in the field for additional testing.

And here what I got from other source:

JVM exceptions Those exceptions or errors that are either exclusively or most logically thrown by the JVM.

Programmatic exceptions those exceptions that are thrown explicitly by application and/or API programmers.


To make it clear, assertion is disabled when the application is deployed, that means if any misbehaving of the application there is NO Assertions Error throw by the VM. So the only way we can find out an error is enabling the Assertions in development. More specific, the programmer has controls over on an error that will be throw. Just like NumberFormatException, it's programmatically error by a programmer giving a wrong value to a method that converts a String to a number receives a String that it cannot convert.

For example,

"two" instead of "2" => convert to 2


I see why you're confusing by the JVM or Programmatically because, in any way these errors throw by the JVM during compile and runtime right?

For the Assertions Error its throw by the JVM during testing not deploying programmatically by a Programmer assertions, and for the NumberFormatException is programmatically mistakes by a programmer. That's what Programmatically really means...programmers have control over errors what they assert or throw or mistakes in programming that will eventually throw a programmatically error not JVM error.

Let me know if it makes sense and correct me if I'm wrong...

[Ikpefua Jacob-Obinyan]

Hello guys, I have been making a personal analysis on the FUNDAMENTAL difference between a 'programmatically-thrown' and a 'JVM-thrown'...The thing here is both events end up in an exception/error thrown at runtime by the JVM.

Difference between Programmatically Thrown and JVM thrown

Case 1:
Programmatically thrown exceptions/errors are those exceptions/errors that occur due to an application and/or Api developers PERSONAL (and off course reasonable) decisions, it is a situation where a developer DECIDES whether an exception/error should be thrown or not. In most cases it has to do with the evaluation of arguments being passed to a method. Observe carefully.

public class Jack {
    public static void main(String[] args){
    	Integer i = 20;
    	Byte b = 20;
    	Jack j = new Jack();
    	j.go(i);
     //j.go(b); my method CANNOT work with Bytes
    }  
   // if users of the method invoke with anything that is 
   // not an Integer throw an illegal argument exception
    void go(Number n){
    	if (n instanceof Integer){
    		System.out.println(n);
   //do stuff that REQUIRES the range of int and above NOT less.
    	} else { throw new IllegalArgumentException(); }
    }
}

___________________________________________________________________________________________

Case 2:
JVM thrown exceptions/errors are those exceptions/errors whose occurence are DECIDED by the JVM independently of the application and/or API developers intentions, for example I CANNOT tell the JVM not to throw an ArrayIndexOutOfBoundsExceptions, when a user is attempting to access an array with an invalid index value.

public class Jack {
    public static void main(String[] args){
    	int i = 3;
    	Jack j = new Jack();
    	j.go(i); // JVM throws an ArrayIndexOutOfBoundsException
    	           // the DECISION is exclusively the JVM's NOT the developer
    }
    void go(int n){
    	int[] ia = new int[3];
    	System.out.println(ia[n]);
    }
}

HTH

Regards

Ikpefua

P.S. @Bert I am wondering what your point of view would look like