Constructor conundrum

I found an interesting constructor type conundrum this week.

I was created a class which held some values as instance parameters, a few strings and an Array. I then extended this class and hard coded some of the String values for the extended class. Basically I thought this was a decent way of placing the hard coded values into a little area, basically containing the hard coded values which could if later get the values from somewhere else (e.g. reading from a file).

The variables where initially private final Strings but then the constructor complained it couldn't see these values in a constructor. I got around the problem by making the values Static because I didn't actually want to change these values for each instance of the class.

The message was

"cannot refer to an instance field variable name whilst explicitly invoking a constructor"

It took my by surprise a bit and then I thought why is it coming out with this message, I thought that basically these variables should be created before the constructor had run. Then I did a bit more thinking and it occurred to me that the constructor has to have a super or call another constructor as the first line. This is because when Java creates a new instance of a class it has to run all constructors of the inherited classes first before it runs it's own constructor. Why does it do this because you might be using some of the values in the extendded class. As we know this means that Java has to run the constructor of Object class and set up its instance variables before it gets round to run the constructor of your class and initialising it's instance variables.

Anyway it was a slightly interesting (or not) not error but just the way Java works, it took me a little by surprise until I thought about it a bit.




If you like this blog or and fancy something a bit less technical with some laughing thrown in then check out my other blog Amusing IT Stories. Which is a blog about funny and amusing stories from the IT environment and the office. It is a mix of news, office humour, IT stories, links, cartoons and anything that I find funny

My first steps using MySql

I have been using MySQL this week which is my first foray into the MySQL world and I'm happy to say it has been a nice easy ride. I haven't done anything fancy with it, in fact I have really only be using it to create two very basic tables but basically I needed a database and MySql is free so it was a good choice.

The download from the site was simple and after I downloaded the latest MySql I downloaded a nice gui tool to go with it - MySQL GUI Tools 5.0. I have been using the Query browser or when I asked another developer which one of the exe's to use he said "the lightening bolt". The lightening bolt was very straightforward to use and creating the table was fairly easy but unfortunately I couldn't add in any rows in the gui dynamically and had to add the rows in using INSERT statements. I don't mind dabbling with an Insert statement but I always forget the syntax (single quotes, who would have thought), so if like me you need a bit of reminding check this link

http://xaprb.com/blog/2006/02/21/flexible-insert-and-update-in-mysql/

or you can look at my code

INSERT into sites (ipaddress, sitename) values
('127.0.0.1', 'localhost');

I wrote some jdbc connection code for oracle, SqlServer, access and as we already have code to do such things I was thought I should add in another connection to fit it in with the rest of our code.

I found a couple of useful links to show me how to connect and the name of the driver, the first one was very useful

http://www.kitebird.com/articles/jdbc.html

http://www.stardeveloper.com/articles/display.html?article=2003090401&page=1

You have to download the MySql jar file and put it in the classpath or import it into your eclipse project. So now I am up and running with my MySql database, a table with some rows in and a JDBC connection and it was all fairly painless.

As Borat would say "HI FIIIIVEE"



If you like this blog or and fancy something a bit less technical with some laughing thrown in then check out my other blog Amusing IT Stories. Which is a blog about funny and amusing stories from the IT environment and the office. It is a mix of news, office humour, IT stories, links, cartoons and anything that I find funny

Sometimes you need to write defensive code

I read a good description of this today, it said defensive programming is like defensive driving, you take responsibility for protecting yourself even if it's the other drivers fault. It's always a bit of conundrum for me, how defensive should I program my methods, classes because it's likely that I am the only person for quite a while to use it, so am I programming defensively for the benefit of others who might never use it.

That said defensive programming is not just about protecting the people who use your code it's about protecting your code so that a big explosion doesn't happen in your code (and thus you getting the blame). A good piece of defensive programming can help debugging immensely by getting nearer to where the actual problem is and not a function erroring just because it's been passed some invalid parameters.

An Example of this is protecting your code from invalid parameters/inputs. If a user can't be bothered to pass in the right inputs don't let your code try and wrestle with it. Check them variables being passed in and throw the appropriate error if they are not valid. An important point here is to make sure you document what is valid and invalid in your JavaDoc.

There are some situations where if you are writing a method inside a class that is private then you know what is going to be passed in so you don't have to write some defensive code because it's only your class which will be called the code and sometimes it's not worth the extra effort of creating the defensive code.

The reason I am blogging about defensive programming is because I used an example of it this week or should I say I had to decide to choose to write some code this week where I thought the best policy would be to return an Array which wasn't null.

In my example I was splitting up a log file in a various String arrays and in the piece of work I was doing, I had a log file and then had to split up the log file into various sections based on IP address. The IP addresses were static (in my tests anyway) so I decided to create some code split the log file into lines and then create 5 String arrays, each array filled with the lines with a certain IP address. What would I do if an IP address didn't have any lines. I decided to to return an array with nothing in

String [] myArray = {};

This meant that the next part of my code processed an array but I didn't have to worry about checking for nulls I just processed it because I knew that there was going to be a blank array rather than return null which would have meant I would have had to check for nulls.

This was one of the tips in Effective Java and it's very useful, don't return nulls they are dangerous and a nasty bug waiting to pop up later when a user manages to get some bad data into the system.





If you like this blog or and fancy something a bit less technical with some laughing thrown in then check out my other blog Amusing IT Stories. Which is a blog about funny and amusing stories from the IT environment and the office. It is a mix of news, office humour, IT stories, links, cartoons and anything that I find funny