things to do with coding (not in any order, maybe the order you'll learn them in)

things not so much to do with coding (but are as important)

INHERITANCE

inheritance is one of those grand sha-bang schemes to give some true-to-life semblance to java.
in using inheritance, one of the most important things is to remember, is when to use it. (seriously!)

it is very easy to overuse inheritance, as almost everything has something in common. ie. my bookcase and my bed, both objects in my room.

say i'd declare a class called Objects_In_My_Room (pardon the underscore, current fad), and then i declare classes such as bookcase and bed from it too. so what we'd have is something which looks like

Objects_In_My_Room            (Parent, or Super class)
     |                      \
     |                       \
bookcase              bed          (Child, or Sub classes)

where each resembles a class. so the properties (and methods) of bed and bookcase both inherit (yes there's that keyword) from the super-class or parent class of Objects in my thingo. sounds reasonable? maybe. i mean, sure, they both ARE objects in the room, but do they really need to be separate classes? let's find out

what methods could we have in the super class then? maybe... isInRoom( ); a boolean method which checks if an object is in a room... OK. how about the subclasses ... what methods (or many methods) could both bookcase and bed have, apart from the aforementioned method (in objects) ??? exactly.

moral of the story: use inheritance when the classes which are "childs" of your parent class, inherit methods (preferably a number of them) which are used in both those class definitions, and bear some linkage to the parent class. sheesh : ) bo-ring!

i mean use inheritance when you have substantial, well justified reasons to. otherwise if it's a small discrepancy or state such as:
protected abstract boolean isInRoom( );
then you'd be better off adding it to the instances made for the parent class (ie. declare it in the parent class). like..
protected boolean isInRoom;

note: the classes you use must ALL be linked, some way or another. ie. you can't have a class called "my foot" and another called "tree" which derives from a super class called "cd player". you'd need a pretty good justification for that, and i don't just mean "they all exist/i can see them" : )        Q.E.D.

protected - what you declare protected in your super class, you can use ONLY in your child class and not outside of that hierarchy. as with the example above, if you did go through and declare a protected method in the objects class, then only bed and bookcase inherit that method/instance variable.

it's often best, if you're using the inheritance hierarchy to declare things you need in subsequent child classes protected; private cannot be accessed outside the class, and public is too accessible. hence protected.

abstract - you can declare a method abstract, or even a whole class! (you just add this in the header line for corresponding definitions). um. when you declare an abstract method, ie.
protected abstract boolean isInMyRoom( );
you only need to declare that method. you don't need to give a definition for that method, but do remember the semicolon after the parentheses for the method. ie. you declare it as you would any given variable.

super - super is an explicit (or is it ilicit?) call to the constructor of your super class (naturally). to call this constructor of the super class (and i think you _do_ need to call it in the constructor of your sub classes), simply insert the following:
super( );
or super ( any_method_parameters_here );
and how about to access methods from the super class?
super.method_name( yadi_yada );

note: you can ONLY call classes from ONE level up in Java. so you quintessentially CAN have subclasses of superclasses which are subclasses in themselves (you may often do this later on), but you can only call from the level above, ie. super.super.super or super.duper is illegal! : )

so how do we call from the class above? time will tell. : )

EXCEPTION HANDLING

anyway. exception handling is one of those super concepts you learn to handle errors in your program. but no, if you keep getting bugging errors they can't handle those (like undeclared variables - you can just declare them!). as you may have seen in my not-so-helpful comp1001 help guide, exception handling consists of a number of "blocks". only here i give mention to them ...

try - the try block is the "bulk" of your code, you would usually have what you would want your method to "try" and do in this block.

catch - here, whatever might go wrong in your try block, is "caught" in the (nicely named) catch block. this block allows you to gracefully fix up the problem, or return to whatever method you can from that ended up going wrong here.

finally - gotta love these ones. no matter what happens, at whatever stage your try block has reached before being "caught" or even if the try goes through it's whole body, the finally block will execute the code in it's block (after the try-catches, naturally). so you do place this block after the try and catch.

quick note: when i say "block" all i really mean is what's in between the { and the }. in other words, what you would normally have in the definitions for methods; print statements, method invocations, whatever you fancy. as dr choo would say ".. doesn't maaatter... "

oh damn. there's also the throw and throws keyword. you'd think these are similar... but they're not.

throw - in your normal source code, if you find that an error is likely to occur, you would want to "throw" an "exception" (discussed later). the semantics for this just follows that, say, taking the if-else statement as example:
if (something happens to stuff up your normal routine prog)
    throw new <whichever_exception_here> ("Error message");
and the <whichever_exception_here> is just the kinds of exception you expect to be "thrown" (which is then caught!)

throws - this is often used in the method header, where the body of that method may throw an exception in itself. ie.
private void readData( ) throws IOException
{ method body }
states that the method may throw an input/output exception.
just note the small discrepancies and where you may need to use them and you should be right.

one of the more key fundaments of this topic is to realise that there exists such a thing as the "try-throw-catch" mechanism. to simplify, i'll use the analogy given in savitch.

ie. we have a rock, known as the exception. whatever we try to do (in the try block) can throw this exception; and thus the exception need be caught in the "catch" block.
remember that whatever the program "throws" must be caught in the corresponding catch block RIGHT after the try block.

ie.

public void whateverMethod( )
{
    try
        { // code here
          // possibly a "throw" statement here, if an exception is likely to be thrown.
        }
    catch
        { // any exception that may be thrown by the above }
}

another thing which you would need to know of is the throws statement in the method header.
as shown above, if you invoke a method which has the POTENTIAL to throw an exception (in the try block), then it must be caught in the corresponding catch block.
    (it is like a throw statement exists in the try block, but is represented by the presence of the method call which has a throws statement).

okay, another few things to note about catch blocks...
- define them in proper order... ie. a FileNotFoundException is derived from an IOException, which in itself is derived from Exception.
so in defining these you would first catch the FileNotFoundException, then IO, then etc...

- in defining these you would write the syntax:
catch (FileNotFoundException fnfe)
{
    //method for catching
}

- so when you "catch" an exception, you pass, in this instance, fnfe as a variable of the class FileNotFoundException (yes it is a class). and then in the method you would have whatever you want to safely run and/or exit the prog. i would have a method which
tells the user the file does not exist and reiterate the method it came from... further techniques for IO handling will be discussed in the relevant section.

ETHICS

Some excerpts from kingston, to keep in mind (concepts & issues); these are an outline of (possible) discussion areas in writing the report:
NB: [..] = Ethics.

[..] & software fallibility:
- we can minimise errors but we can't eradicate them
- consideration of the user perspective
- concept of "reuse"
- cost benefit analysis of having the database system (as compared to others, etc)

[..] & international law:
- is it ethical to store information in a country without the same strict statutory controls?
- remote databases, used to store information, which is problematic on a local basis are referred to as "data havens"

[..] & data compression:
- two types: "lossy" and "lossless"
- lossy: a lesser type, small losses to help in compression ability
- lossless: no compression, remains the same (possibly large) file
- keep this in mind when the possibility of the database to be "extended"

[..] & the storage of data:
- should all information be easily accessed? (ie. firewall, protocol)
- should difficulty be preserved?
- does changing the storage medium change the nature of the information?

[..] & data collection & data use:
- what happens to information provided? (spamming etc)
- does the information have the possibility of being misleading?

[..] & differential expertise:
- does information not intended for the user have the possibility to show up to the user?
- does expertise entitle an individual to disregard another's expectations?

[..] & user specifications:
- common problems in systems analysis is determining what the users want, as distinct from what they say they want.
- are there different levels of access permissions for personnel?

[..] & programming:
- what if the users expect software maintainability as part of the final product?
- (is this situation satisfied with the current example)

recommended site: Australian Institue of Computer Ethics