Java Try Catch

Kua

Kua

Associate
Joined
21 Jul 2008
Posts
512
Location
Lancaster
There are no errors but the driver won't enter the try block at the bottom. "Test" should print to the console, but it doesn't. I.e. the Employees aren't instantiated.

Code:
public Employee(String name, String gender, String DOB, String jobTitle, int salary) throws InvalidDateException{
		employeeName = name;
		employeeGender = gender;
		employeeDOB = DOB;
		employeeJobTitle = jobTitle;
		employeeSalary = salary;
		
		//Some problem with using this if statement
		if(validDOB(DOB)==false){
			throw new InvalidDateException("Please enter date in format: DD/MM/YYYY");
		}
	}

public boolean validDOB(String date){
		if(date.matches("[0-9]{2}/[0-2][0-9]/[0-9]{4}")){
			return true;
		}
		return false;
		
	}

Code:
public class Driver {
	
	public static void main(String[] args) {
		
		
		
		//Create space in memory and initialise *fields*
		//WHY WON'T IT ENTER THE TRY-CATCH??
		
		try {
			Employee fred = new Employee("Fred Flinstone", "Male", "02/02/1960", "Manager", 25250);
			Employee lisa = new Employee("Lisa Simpson", "Female", "09/05/1981", "Sales Staff", 19750);
			Employee charlie = new Employee("Charlie Brown", "Male", "03/11/1950", "Sales Staff", 17500);
			System.out.println("test");
		} catch(InvalidDateException e) {
			e.getMessage();
		}
}
}
 
Fred, Lisa or Charlie are throwing the InvalidDateException and causing it to jump to the catch before the print statement for "test" occurs...

In your catch instead of suppressing the exception why not make it more visible in your console with e.printStackTrace(); (I think that's the right method). That way you'll see more clearly why it never reached the print for "test".
 
Last edited:
Fred, Lisa or Charlie are throwing the InvalidDateException and causing it to jump to the catch before the print statement for "test" occurs...

In your catch instead of suppressing the exception why not make it more visible in your console with e.printStackTrace(); (I think that's the right method). That way you'll see more clearly why it never reached the print for "test".

You are right, use e.printStackTrace(); and you can see what your problem is.
 
Or just use a decent IDE.

Using an IDE such as Eclipse and learning how to use the debugger is one the most important skills you can learn as a programmer. Being able to step through your code line by line really gives you a good picture of what's going on. It's also a really good way to learn how programming constructs operate when you're new to it.
 
Yes. You were all bang on. I was rather stupidly thinking e.getMessage() printed to the console, but it just returns a String.

Noob question: How can you tell I'm using Eclipse?
 
If you double click in the left hand column next to a line of code in Eclipse it will place a little blue dot which is called a breakpoint. If you then go to Run > Debug (F11) you will start executing your program with the debugger running, it will probably ask to switch you to the debug perspective (click yes). When your program hits the line with the breakpoint, execution will halt and you'll be able to look at the state of your program including any variables in context at the breakpoint. You can then use the controls on the toolbar to do things like step over to the next line or step into a statement. Have a play around with it, it's the best way to pick it up and can be very useful.
 
I'd say that should be and, not or :p

Exceptions should never be suppressed, and at the least logged. :)

It's definitely a case of 'or' (not in the boolean logic sense though).

You can either **** around using printStackTrace() yada yada or you can just make your IDE start working for you.

I can't remember the last time Visual Studio made it difficult for me to explore the details of an exception. It is so 'in your face' that you can't miss it either. Of course this guy is using Java/Eclipse etc, but I'm sure Eclipse has something similar in its debugger for the whole user experience around presentation of exceptions within the IDE.

"should never [swallow an exception]" is very idealistic. I can think of several situations OTOH where there is simply no other way. If you want to implement a TryParse for System.Guid in .NET you quite simply will have to catch the FormatException and return a false. Because the BCL doesn't provide any exception-free way of parsing Guid's. Admittedly this has been fixed in .NET 4, they added a TryParse.
 
I was referring to the fact that if an exception is raised, you'd want to know about it. Specifically at run time. :)

There's always an exception that prove the rule! (Pun partially intended)

Using exceptions for Logic is a code smell and should be avoided, but not always possible with closed libraries/dependencies (ala your example with System.Guid) that leave you no choice. But to choose to use Exceptions for logic is sloppy. :)
 
Using exceptions for logic, flow control etc in an unwarranted manner is more than just a code smell. It's an utter foul stench!
 
Back
Top Bottom