Nitemice

Because I’ve been spending all my time studying lately, the only thing I’ve had time to write is study notes. So I thought that I’d make the most of them, share a bit of my new knowledge with you, and give you a quick crammer’s guide to some of the topics from each of my subjects this semester. The information probably won’t mean a whole lot to you if you’ve never learnt anything about the topic before, but if you have, hopefully, this’ll clear up a few things for you.

This one’s about Java Programming 1. This subjects covers the basics of writing programs in Java, using arrays, classes, and exception, as well as how to write to files.

Note: For most topics, Oracle’s Java Tutorials is a great, comprehensive resource, so have a read of it here: http://docs.oracle.com/javase/tutorial/. Some of the stuff can be hard to find from their main page, so just Google it like this: http://goo.gl/sZCfy

There’s also JavaDocs too, for more technical stuff: http://docs.oracle.com/javase/7/docs/api/

Exceptions

When you first encounter exceptions, there are two aspects that can be confusing: what do I do with them, and why would I create my own?

The idea of an exception is that it’s a way to signify an error has occurred without having to invent and use some overly-complicated system of return values and/or variables (Boolean or otherwise). Normally, when you call a function which could have a problem, e.g. it can’t do what it’s suppose to for some reason, you would use a return value of false to signify that it’s failed. However, it you’re writing a program with lots of bits, maybe multiple classes with multiple functions, and you call a function that called a whole chain of others, it’s not really practical to have to return a false value all the way back because one of the inner functions failed. And not only that, it’s a real pain to find where your failure is even occurring!  The advantage of using an exception instead of returning a value is that once the exception is thrown, it will “float” straight up past all the preceding functions until it reaches a level at which code has been written to deal with it. It there’s none found, Java will crash the program and display the exception.

While, on first glance, that may not sound so useful, it actually really is. One of the main advantages of this approach is that it means you’re able to write a chunk of code, a function or a chain of functions, knowing  that they’ll fail under a certain circumstance, and use it over and over in a variety of different programs. All you have to do is, whenever you call it, you do it from within a try block, with a catch block for that type of exception to deal with the resulting error. For example, I could write a function that looks up a given word in a given database, and returns its position. If it doesn’t find the word, it throws an exception. This way, my function doesn’t have to worry about what to do because the word isn’t found. It just throws an exception and lets me deal with it. I could even have another function calling that function, and it too doesn’t need to worry about the error. All it needs is a declaration to say that it might pass on this exception. At whatever point I want, I have a try block, which contains the code that calls this chain of function as well as anything that should only happen if no exception is thrown. If there’s no exception, it’ll run all the code, and move on. If there is an exception, it’ll look for a relevant catch block that can deal with the thrown exception. It won’t just stop at any old catch block, it has to be one related to the type of exception thrown. When it finds it, it’ll run the code in that block, and then move on to the rest of the function where the catch is found.

So now you why you want to use an exception at all, why do you need to create your own? There are lots of different types of exceptions built into Java, each for a different specific occurrence. They’ve each got different names like IOException and NullPointerException which tell you what caused them, and that’s basically the real reason you’d want to create your own type of exception in a program. By defining an exception, which is actually defining a subclass of the Exception class, you can name your exception whatever you want, as well as adding extra features and information to it. For example, continuing the example above, I could create a WordNotFoundException that I could throw when the word isn’t found. I could add an instance variable to it to hold the name of the database, so that when my exception is caught, there’s a way to find out what database was being searched. It’d need a constructor, and all that jazz, but it’s actually pretty straight forward.

“But what if I don’t want or need to add any extra features to my exceptions?” I hear you ask. Well then, you can just use the plain-old vanilla Exception. Like I mentioned earlier, it’s the superclass of all the other exceptions, and provide them with their main functionality. And you don’t need to worry about how you’re going to identify the cause of your exception because there’s an instance variable that you can used to store just that!

The only problem with this is catching these exceptions will result in catching of any exception, so if something unexpected happens, it’ll still get caught & dealt with as you’ve coded. So, really…this isn’t an advisable approach. The happy medium is to create a new Exception class for your program, but leave it vanilla. You can then use this one exception class for any errors in your program, and just using the message variable to store the cause, as mentioned above. Of course, if there’s a possibility of these exceptions being thrown in conflict with each other, you may still need multiple exception classes to separate them out, but for most little programs, the one should be just fine.

For more information on exceptions, read the JavaDocs: http://docs.oracle.com/javase/tutorial/essential/exceptions/

Or this: http://www.javaworld.com/javatips/jw-javatip134.html

Other Tips:

• Don’t forget the semicolon at the end of each line;
• Anything within a finally tag will be executed after catch, or if it hasn’t been caught, before the exception floats up;
• Continue starts a loop again at the next iteration (e.g. i=1  –>  i=2), Break skips straight out of the loop altogether;
• You can’t create an instance of an abstract class, except if it’s a empty instance (e.g. an array of an abstract class, which contains instances of subclass objects);
• Any abstract methods must be totally empty (public abstract double Calculate();), and must be implemented in subclasses, unless the subclass is also abstract;
• Variables are checked in the following order (the first found with the matching name is used): Loop-local, Method-local, Passed to method, Class-level variables;
• The order of operators is: Brackets , New, Dot (.), Incrementals (++Y, Y++, –Y, Y–), Multiplicative (*, /, %), Additive (+, -), Relational (<, >, <=, >=), Not (!) , Equals (==), [Logical] And (&&), [Logical] Or (||), Assignment (=, +=, …);
• If an operation involves two integers, it will always produce an integer, even if assigned to a double. A double needs to be part of the operation;

Until Next Time,

Nitemice

Related articles

• Throwing exceptions as well as catching exceptions? (stackoverflow.com)
• Object Oriented Concepts: Before we go in detail, (elktaoui.wordpress.com)
• Why Abstract Classes have Constructors? (reconstructedcodes.wordpress.com)
• Java Keywords and their Uses (codingtoall.wordpress.com)
• Catching all exceptions (yesodweb.com)
• Crammer’s Guide – Y01S01: Database Theory (nitemice.com)
• Crammer’s Guide – Y01S01: Computer System Fundamentals (nitemice.com)