Monday, 10 October 2011

Java: Representing and Throwing Exceptions

To comments people: Sure I might be able to do all kinds of apps, but I'll look into it more when I like...can.
And no, I don't work as a programmer (yet), I'm barely ahead of what I post, so I still have a way to go :(

Guess how exceptions are represented in Java? Like everything else, pretty much, as objects! This actually allows information about what happened to cause an exception as well as where in the source code it happened, to be transferred easily around a program. A built-in Java class in the libraries contain quite a few exception classes, all of which are subclasses (direct or indirect) of the superclass
Throwable. Most exceptions are a subclass of Exception, itself being a subclass of Throwable (hence the indirect). There is another set of exceptions that you really don't want to come across, and those are of the class Error. These, however, are based more around internal errors, and really really should not happen. If it does, the only way to deal with it tends to be termination of the program.


So what do we do when an exceptional event occurs? We need to throw an exception! And since exceptions are represented as objects, this involves actually creating one first. So back to our example of popping a value off an empty stack of Car objects. This is one of those situations where you want to throw an exception. The pop() method itself isn't really equipped for dealing with this, so it should use the exception mechanism to force the code that actually called the method to take responsibility. Basically, it's not pop's fault, but whichever part of the code that called pop on an empty stack.

To implement this, we first need an exception class that we can use. If there isn't a default one that's fitting, you can make your own, fairly easily. AND HERE'S HOW:



The class needs to be a subclass of Exception, and normally (not necessary, I guess) you'll have 2 constructors. A default constructor that calls the superclass with a default message, and another that takes a string parameter, in case you want a more specialized message. Voila, you're done creating an exception of your very own. You can play with it and love it and have sleepovers and everything.

You probably could have found a fitting exception in the JDK library though, but unless you know what you're looking for, it could take more time to find than to write your own. Just saying.

Anyway, the next stage is to put this new class to use. First, we need to follow the method that uses the exception with "throws BadPopException". Then, we need some conditional within the pop() to throw the exception. Here's an example, taken from a previous stack, because screw rewriting that.


As we see,  the method is specified to throw some exception. Our condition in this case is easy, just throw the exception if the stack is already empty, otherwise pop the element! So now that was implemented, in the main method I just told it to keep popping, and it resulted in the above error message!

Simple-ish. There's just a couple more things to do before the chapter is over! Also, since my posts are often quite long, I've tried using the jump break. Hopefully it'll make the main page less ugly. That's it for now..Questions welcome! Comment, follow, subscribe, share etc, and see you tomorrow!


And as part of a shameless plug for a friend, if you're interested in classic movies/books/music, visit his site here (fixed), and feel free to throw loads of criticism at us. 

5 comments:

  1. No i understand, thanks!
    keep posting.

    ReplyDelete
  2. That's a good follow up. I would suggest you to add what kind of stuff you could do with that. It would make it easier to understand.

    ReplyDelete
  3. Yeah, this is becoming new for me. I think we just barely covered this in class.

    ReplyDelete
  4. I guess I understood. :S

    ReplyDelete