This week we're going to look further into dealing with parameters and properties in Java applets. At the same time, we're going to learn a thing or two about exceptions in Java.Since last week we talked about the hypothetical and general nature of parameters, this week we're going to look at a relatively concrete example. In this case, we have some sample code representing the "proper" way in which to handle an applet parameter.
Imagine an applet that just displays some arbitrary information by scrolling it through a window. It's pretty obvious that it would be handy to be able to plug numbers into it for different circumstances on the fly, rather than rewriting and recompiling it for every different usage, and having different versions of it lying around. In this case, just being able to give our applet a single number as a parameter will suffice--we want to select how fast the text will scroll.
We've shown how this looks in HTML:
<APPLET CODE="some-applet.class" WIDTH=100 HEIGHT=100> <PARAM NAME=DISPLAYSPEED VALUE=250> </APPLET>
Here's how it should look from inside your applet:
int displaySpeed = 0; ... String displaySpeedString = getParameter("DISPLAYSPEED"); if (displaySpeedString != null) { try { displaySpeed = Integer.parseInt(displaySpeedString); } catch (NumberFormatException e) { displaySpeed = // SOME DEFAULT VALUE. } }(This is adapted from the example on the Sun Java Tutorial page on parameters.)
We'll grant you, this looks more complicated than it should be, but it does more than it might seem.What you're seeing here that's likely to be confusing is the use of exceptions. Once again, the only reason exceptions are likely to be confusing is that those who talk about them insist on clinging to the various bits of jargon that go along with them.
Don't get hung up on terms like trying, throwing, and catching. Forget about them for the moment. Just think about how you might design something in a language to handle unexpected situations that might arise while executing someone's code. If, as in this case, someone has written a routine--
Integer.parseInt()--to take a String and turn it into an Integer, what should happen when, say, someone drops a string on this routine that doesn't have any numbers in it? That, in effect, can't be translated into a number at all?The accepted, run-of-the-mill way this problem is addressed in many languages is, well, nonexistent. A person writing routines such as that one must decide what they want to do in every instance of such a problem. Should the whole program grind to a halt? Should there be a predefined thing passed back to the calling routine, instead of the result, which indicates failure? Should some error flag be set?
Exceptions are a high-gloss, standardized and generalized way of dealing with situations where the unexpected might happen. Rather than marching lock-step through instructions which either work, or crash, your programs will try things. They will know what to do if your tries don't work. That's catching something. Routines that may fail, instead of taking some arbitrary action, will instead signal their failure with an exception; this is the act of throwing an exception.
Don't worry, we'll provide all the details soon enough - and of course, there's a huge section of the Sun Java tutorial devoted exclusively to exceptions. In the mean time, our elementary explanation should suffice. In the case of the sample code above, we use the
getParameter()method we mentioned last week to find the value we want, if it exists. And we check to see if it does. If there actually is a value produced that's associated with our parameter, it's represented as a string--rather natural, considering that the parameters are entered and processed as text, not numbers.We, on the other hand, need to deal with it as the integer we hope it is, but we can't trust our user to have properly entered a value; thus, we try to use the handy
parseInt()routine in the Integer class to translate. However, as we mentioned above, this kind of parsing is an uncertain operation at best; should it fail, parseInt() will throw a NumberFormatException--one that, fortunately, we are prepared to catch. Note, for future reference, that an exception is an entire object in its own right, instantiated at the throwing point and received at the catching point. This is of great potential importance later.You might say that, in this case, it wasn't necessary for us to use exceptions; we could have used a far simpler technique, such as having a parsing routine return a negative number (a clearly impossible window size) in the event that the parameter string was incomprehensible. The calling routine could then check for this condition with an if statement. But when your programs get large, and the potential sources of discord and error grow in number, the exception as a standard, reliable method of dealing with uncertainty becomes more and more obvious as a superior tactic.
