Exception

[David Starr]

Wrestling with panic.

Embarassed to say that I cannot get the main method around this in some form. Please inform me how to get the main method to make this runnable:

public class IOOBE {

  public void forceIndexOutOfBoundsException() {
    List fishFamily = new LinkedList();
    fishFamily.add("Eastern");
    fishFamily.add("Western");
    System.out.println(fishFamily.get(0));
    System.out.println(fishFamily.get(1));
    }
}

[fred rosenberger]

what do you mean by "around this"? Methods cannot be nested in java - a method cannot be defined inside another method.

if you want a main method, just write it such that it is not inside your forceIndexOutOfBoundsException method, or vice versa.

[Matthew Brown]

Well, you've created a method. So you need to call that method. But it's a non-static method, so first you need to create an instance of the class.

So that method can be called from anywhere by going:

IOOBE ioobe = new IOOBE();
ioobe.forceIndexOutOfBoundsException();

A main method can be in any class, so you can create a new class to hold it, or you can add it to this class.

[David Starr]

import java.awt.List;
import java.util.LinkedList;

public class IOOBE {  
    
    public void forceIndexOutOfBoundsException() {  
      List fishFamily = new LinkedList();  
      fishFamily.add("Eastern");  
      fishFamily.add("Western");  
      System.out.println(fishFamily.get(0));  
      System.out.println(fishFamily.get(1));  
      }  
  }

public class IOOBETest {

	public static void main(String[] args) {
		IOOBE ioobe = new IOOBE();  
		ioobe.forceIndexOutOfBoundsException();

	}

}

[Ivan Jozsef Balazs]

What is exactly your problem?

[David Starr]

I want to understand this exception, but cannot yet perform a test of it. I would like to run it correctly as well as in a way it throws an exception. I was looking at the assignment of 0 and 1.

[Jeff Verdegan]

David Starr wrote:I want to understand this exception, but cannot yet perform a test of it. I would like to run it correctly and then so that it throws an exception.

You posted some code. But you need to TellTheDetails(⇐click). Exactly what do you expect that code to do? And exactly what is it doing instead?

[EDIT: After a second glance, it's easy to see what the problem is. I'm not letting you off the hook that easily though. ]

[David Starr]

I want to understand this exact example, why do I have 'new LinkedList(); underlined, as well as both .get

The console is showing this:

Exception in thread "main" java.lang.Error: Unresolved compilation problems:
Type mismatch: cannot convert from LinkedList to List
The method get(int) is undefined for the type List
The method get(int) is undefined for the type List


I want to learn. This is always my last resort. At this point I am frustrated. Additional examples do not help. I want to understand this one given.

[Jeff Verdegan]

The error messages are telling you exactly what's wrong. LinkedList has nothing to do with List.

LinkedList is... a subtype of List. However,
LinkedList is NOT a subtype of List.

No, there's no typo or other mistake in what I wrote. It is correct. Now go back and look at every line of your code more closely. And if it doesn't jump out at you, look at the javadocs for every fully qualified class name referenced in those error messages.

It's a really simple mistake, but it will be good practice for you to exercise the care needed to check your assumptions and spot it.

[David Starr]

So, when I am learning and being presented with an example, I generally expect the example to focus upon what is being taught, not in addition to side topics/issues. I realize a constructor should be

LinkedList fishFamily = new LinkedList();

I did not know if this was a new thing based upon exception handling. I got it all to work. Tested with 0, 1 (printed Eastern then Western on next line) and then I tested it with 1, 2 . It worked with 0 and 1 and got an error for 1, 2 but that was not an expected error. It is in reverse of what I thought. It gave the exception message then printed Western. I would have thought it would have printed Eastern then the exception message.

import java.util.LinkedList;

public class IOOBE {  
    
    public void forceIndexOutOfBoundsException() {  
      LinkedList<String> fishFamily = new LinkedList<String>();  
      fishFamily.add("Eastern");  
      fishFamily.add("Western");  
      System.out.println(fishFamily.get(1));  
      System.out.println(fishFamily.get(2));  
      }  
  }  

public class IOOBETest {

	public static void main(String[] args) {
		IOOBE ioobe = new IOOBE();  
		ioobe.forceIndexOutOfBoundsException();

	}

}

Second run (test run) error message:
Exception in thread "main" java.lang.IndexOutOfBoundsException: Index: 2, Size: 2
at java.util.LinkedList.checkElementIndex(LinkedList.java:553)
at java.util.LinkedList.get(LinkedList.java:474)
at p364ioobe.IOOBE.forceIndexOutOfBoundsException(IOOBE.java:12)
at p364ioobe.IOOBETest.main(IOOBETest.java:7)
Western

So why does the error run this way? Seemingly reversed from what I expected.

[Jeff Verdegan]

David Starr wrote:So, when I am learning and being presented with an example, I generally expect the example to focus upon what is being taught, not in addition to side topics/issues. I realize a constructor should be

LinkedList fishFamily = new LinkedList();

No. List fishFamily = new LinkeList(); would be better.

What is the fully qualified class name of LinkedList? Can you paste a link to its docs?

What is the fully qualified class name of List? Can you paste a link to its docs?

Tested with 0, 1 (printed Eastern then Western on next line) and then I tested it with 1, 2 . It worked with 0 and 1 and got an error for 1, 2 but that was not an expected error. It is in reverse of what I thought. It gave the exception message then printed Western. I would have thought it would have printed Eastern then the exception message.

The println() calls go to System.out. The error message and stack trace go to System.err. They don't necessarily get flushed in the order that stuff is sent to them. Probably the println() for #1 wasn't enough to force a flush of out, but the amount of stuff in the stack trace was enough to force a flush of err. If you call System.out.flush() after every println(), you should see the expected order. (Note that you don't want to do that in general. This is just to demonstrate that the code executes in the order you think it should.)

[David Starr]

java.util.LinkedList
There are two 'List':
java.awt.List
java.util.List

Interesting on the

The println() calls go to System.out. The error message and stack trace go to System.err.

[Jeff Verdegan]

David Starr wrote:java.util.LinkedList
There are two 'List':
java.awt.List
java.util.List

And when you looked at the docs for LinkedList and for those two Lists, and then looked again carefully at the error messages, did that give you a clue as to what the problem might be?

Interesting on the

The println() calls go to System.out. The error message and stack trace go to System.err.

Yeah, that's not a new thing. It goes back at least to C's stdout and stderr, and I would guess probably further than that. I assume it came from when there was no such thing as a GUI, and programs usually just spit out their outputs to a printer or tape file, and that it provided an easy way to separate the useful, normal output for a program from any diagnostics or logging or error messages into two separate channels, e.g. one printout to deliver to the user with his results and the other for programmers to study for bugfixes and enhancements. Most of the time it doesn't cause a problem, but if you're not aware of it, it can lead to some confusing results, as you discovered.

[David Starr]

The java.util.list appears to be the correct one since it has the Throws as IndexOutOfBoundsException indicated in the API, and so this one would also be the correct one to import. It runs now. Still even with flush it prints Western prior to error:

import java.util.LinkedList;
import java.util.List;

public class IOOBE {  
    
    public void forceIndexOutOfBoundsException() {  
      List<String> fishFamily = new LinkedList<String>();  
      fishFamily.add("Eastern");  
      fishFamily.add("Western");  
      System.out.println(fishFamily.get(1)); 
      System.out.flush();
      System.out.println(fishFamily.get(2)); 
      System.out.flush();
      }  
  } 

public class IOOBETest {

	public static void main(String[] args) {
		IOOBE ioobe = new IOOBE();  
		ioobe.forceIndexOutOfBoundsException();
	}
}

-----
Western
Exception in thread "main" java.lang.IndexOutOfBoundsException: Index: 2, Size: 2
at java.util.LinkedList.checkElementIndex(LinkedList.java:553)
at java.util.LinkedList.get(LinkedList.java:474)
at p364ioobe.IOOBE.forceIndexOutOfBoundsException(IOOBE.java:14)
at p364ioobe.IOOBETest.main(IOOBETest.java:7)

[Jeff Verdegan]

David Starr wrote:The java.util.list appears to be the correct one since it has the Throws as IndexOutOfBoundsException indicated in the API

You're on the right track. However, the reason it's the right one is because the docs for java.util.ArrayList say that it implements java.util.List, not java.awt.List. Therefore, ArrayList IS-A java.util.List.

Still even with flush it prints Western prior to error:

Well, yeah, that's what you'd expect, right? You print out the element at index 1, which is Western, then you try to get 2, which doesn't exist, so you get the exception.

[David Starr]

How would a person know to go to ArrayList, does not seem straightforward enough to me?

You are totally correct on the how the output to console displays. Thanks for pointing that out.

[Jeff Verdegan]

David Starr wrote:How would a person know to go to ArrayList, does not seem straightforward enough to me?

Just out of the blue? Like, "Well, this is the first time I've ever used Java. Hmmm... I want to have a bunch of things stored together. I know! I'll use java.util.ArrrayList!" No, that doesn't happen.

But at some point during our studies we come across something like the Collections section of our tutorial, and we learn about the existence of these classes. Even if we don't remember all the details (and we won't), if we remember at least one class name, we can go to the javadocs and refresh our memories as to what classes and interfaces are available, what services they provide, and how they relate to each other.

However, by the point where you were using that code, whether you wrote it yourself or copied it wholesale from somewhere else or copied and adapated something, you should now know enough to read and think about and try to understand error messages, and you should know how to use the javadocs when you get errors telling you that things are what you thought they were. And just as importantly--more importantly perhaps--you should learn to check your assumptions. Always. When something doesn't turn out as you expected, look at what your assumptions are (such as in this case, you assumed that java.util.ArrayList was a subtype of java.awt.List), and then investigate to see which ones are wrong. This stuff is what I was trying to push you toward.

[David Starr]

Jeff, I appreciate this.

I have heard how important the Javadocs are. I wish there were examples in them, and that they would be more easily searchable. Excuses. I do not want to have excuses. It is taking me longer than I would like to really learn this material. Just as I think I understand something, there is not only additional material on that topic, but more overall topics to learn at the same time. I am going through the tutorials, just not as quickly as I would like. Collections are a ways away (chronologically speaking). I am also learning the basics via the Oracle Fundamentals from text and am on chapter 9 of 10 (Handling Exceptions).

As I encounter situations such as this one and the one a while back regarding variable scope, it is helpful for me to gain understanding and learn about the angles coming at me. For example, in this example, the word representation of the word ‘List’ has how many different meanings and Java Language ‘aliases’! We have the English word applicable in this case (not random), then two different subclasses.

Ahh, this learning process is tough to go through, but once my mind can be bent around the understanding it is a confidence builder. I just hope one of these years I can actually make a living with it. Another thing I am doing is working on a Web project (early stages right now) where I put a bunch of new things (to me) together, such as Linux, Spring, Tomcat, perhaps JBoss, MySQL, and the list goes on. Doing that is a good ‘break’ from the pure syntax and language stuff, however, when I get stuck with all that it is nice to be able to come back to something more straightforward. (Hey, did I just say that word in a positive light?!!)

[Jeff Verdegan]

David Starr wrote:I have heard how important the Javadocs are. I wish there were examples in them, and that they would be more easily searchable.

They are absolutely essential. If you don't have a browser window open to them at all times while programming, you're doing it wrong. They're easy to search if you know the name of the thing you're looking for, but not so much if you just have a general idea of the kind of thing you want to accomplish. Fortunately, Google exists. Any time I want to do something in Java that I've never done before, I'll google something like how to XYZ in java. Often times the top few results that come back point right to classes in the javadocs that I never knew existed.

Java does have a large core API provided with it, and there are a lot of libraries out there for common tasks. The downside is that no individual can ever be thoroughly knowledgeable about more than a small faction of it.

It is taking me longer than I would like to really learn this material. Just as I think I understand something, there is not only additional material on that topic, but more overall topics to learn at the same time. I am going through the tutorials, just not as quickly as I would like.

It's a lot to take in. The learning curve never ends, and more gets added faster than anybody can climb it. Don't get discouraged, you're definitely not alone.

This is a good read for somebody looking to learn a new craft. It may sound discouraging, but I'm suggesting it so that you'll have realistic expectations, and can therefore manage them, know what to expect, and plan effectively: http://norvig.com/21-days.html

[Campbell Ritchie]

David Starr wrote:Jeff, I appreciate this.

He is being very helpful

I have heard how important the Javadocs are. I wish there were examples in them, . . .

Unfortunately the Javadoc comments are written for experienced programmers, and examples of code are few. You will find more code examples in the Java Language Specification, but that can be even more difficult to understand. That is why they are accompanied on the websites by the Java Tutorials, which Jeff gave you a link to part of yesterday. Read that link and go from there to the whole of the Tutorials. But it is too large to read all at once.

[David Starr]

Agreed. I am thankful, and appreciate all the guidance, direction, and patience. Seeking to understand, I am humbled at this Goliath heap of language learning. I do not believe most people are willing to patiently help, not sure why that is. I have heard of (and experienced myself) that many people do not have the time, patience, or desire to help others learn programming. It is a rare commodity.

[David Starr]

Overall, is the topic of Handling Exceptions one of the more difficult ones to grasp? I am really beat up by this one.
The other challenging one was Understanding Methods and Variable Scope.

01. Packaging, Compiling, and Interpreting Java Code
02. Programming with Java Statements
03. Programming with Java Operators and Strings
04. Working with Basic Classes and Variables
05. Understanding Methods and Variable Scope
06. Programming with Arrays
07. Understanding Class Inheritance
08. Understanding Polymorphism and Casts
09. Handling Exceptions
10. Working with Classes and Their Relationships

[Jeff Verdegan]

David Starr wrote:Overall, is the topic of Handling Exceptions one of the more difficult ones to grasp?

It can be difficult, yes. The actual rules and behaviors aren't particularly complex, but whole concept is a different way of looking at the flow of execution than what you've been used to up until now. I think that may cause a lot of confusion. The basic philosophy--and I don't know how well this is explained in any particular book or tutorial--goes something like this:

Without an exception mechanism, we might write code something like this:

result = step1();
if (result is error) {
  handle error
  clean up any resources we're using
  return error result from this method
}

result = step2();
if (result is error) {
  handle error
  clean up any resources we're using
  return error result from this method
}

// ... etc. ...

That's a bit of an extreme example, but the point is that we do a little bit of work, check for errors, and if we find any, clean up and then exit the method. The error handling and cleanup work is right inline with the happy path code. That makes our code hard to read and hard to write. While it's obviously true that error handling is important, it's not the reason we're writing this code, and most of the time, there won't be errors. It would be nice if we could have all the happy path code--the code that does the real work, the whole reason we're writing this app--in one place, and the error handling code separate. Something like this:

step1();
step2();
step3();

if there were any errors above {
  handle them
}

now clean up and exit this method

Now we can clearly see that the way this code works is by executing step1() and then step2() and then step3(), and we can add, remove, or rearrange steps easily without having to carry around error checking and handling code for those steps as we do so. And we can in fact write code like that even without an exception mechanism in the language, EXCEPT (no pun intended) that without those intervening error checks, we'll continue to go on to step 2 and 3 even if step 1 failed.

With an exception mechanism, however, it looks like this...

try {
  step1();
  step2();
  step3();
}
catch (whatever problems occured that we might have wanted to handle) {
  all error handling here in one place
}
finally {
  all cleanup here in one place, regardless of whether any problems occured,
  then we leave this method
}

[EDIT: I forgot to mention that if any of our happy path code in the try block throw an exception (which is now our way of indicating a problem, rather than returning an error code), then we jump straight to the catch block for handling that exception, if there is one, completely skipping the rest of the try block.

After the catch block is done, or straight after jumping out of the try block if there's no catch for the exception that occurred, or after the try block completes normally if there were no exceptions, finally is executed--always--so that we can clean up before exiting the method.]

THAT is the main point behind exceptions--the ability to separate happy path "real work" code from the error handling code from the final clean-up-on-the-way-out code, but still stop executing the happy path code if an exception occurs, and still do the cleanup code at the very end, regardless of whether an exception occurred.

There are more details and rules you'll have to learn of course, but keeping that history and motivation in mind might help you fit the details into the bigger picture, and give you a better understanding.

[David Starr]

Okay that makes sense. I get a lot out of high level views and seeing how this fits in the overall big picture of things.

So it seems it is sort of a balance between two extremes. Things that need to be handled if they should occur. The error checking wraps around the code, it seems is the idea.

I have been looking at a lot of snippets of code and then attempting to understand where does the main method fit in, so that I can test. Then while I am testing, since these are exceptions, I find myself wondering if what I am experiencing is what I should be experiencing since it is an exception rather than a smooth running program. So, then I try to get it to run correctly, but if I do not fully understand how the exception is supposed to work -- it is a circular experience.

Of course in order to find out how the exception works I need to check the API to see what methods throw exceptions and what classes are subclasses, and what is checked compared to unchecked. The API is somewhat of a cryptic skeletal document steeped in hotlinks. It is what it is, and I know I had better get used to it.

Nevertheless, as I am typing this I am realizing this topic actually brings a lot of things together and checks for exceptions WITHIN development. While it IS a part of development it is a different form of development than what I am used to. So, you are right it is a bit different for sure.

[Campbell Ritchie]

Another part of the philosophy of Java is that it is Exception, Exception, Exception. No error codes or error conditions. If something goes wrong you should always use an Exception.

The main method is for starting your code execution off.