Java exception handling question

[jm20]

Is this an example of good coding for exception handling ? or should I put the try catch statement in the main method and do them individually.

 

[Kilrsat]

Originally posted by: jm20
Is this an example of good coding for exception handling ? or should I put the try catch statement in the main method and do them individually.

I'd say not a good use of exceptions. The Employee constructor is being called from somewhere else, and the exception deals with checking the arguments passed to that constructor. As you have it right now, someone can pass in an invalid number, and the code will continue executing, it will simply print an error message. The caller can continue to use that Employee object, even with its invalid data.

What it looks like you want is if they pass a value that isn't between 6 & 50 for the hourly wage, the employee object is not created. This means the Employee constructor needs to throw the exception, and make it the caller's responsibility to either a) simply use valid values or b) handle their own mistakes.

Of course, with this style, the documentation needs to follow. So your Employee class should clearly be labeled under what values for the arguments it works and what values for the arguments trigger an exception.

 

[jm20]

well this is just for a assignment for my java class, and those are the only objects ever being created, as im supposed to create a over, under, and within value to use the exception. Right now I satisfy those

so the lesson here is to try catch in the main while creating the objects to prevent invalid ones from being created ?

 

[MrChad]

Originally posted by: jm20
so the lesson here is to try catch in the main while creating the objects to prevent invalid ones from being created ?

Sort of. As kilrsat mentioned, you need to think about

1. Why the exception is being thrown
2. What the consequences of the exception should be

Those two pieces of information should help you determine where you should catch / handle the exception as well as how you should handle it.

 

[jm20]

ty good to know for future reference

 

[torpid]

Originally posted by: jm20
Is this an example of good coding for exception handling ? or should I put the try catch statement in the main method and do them individually.

No. First off your exception message does not contain any useful information. If this were a big project even the developer would have no idea what it means without looking over the stack trace and line numbers.

Secondly, are you sure you are supposed to swallow the exception and not throw it?

Thirdly, you should not be setting the private fields to the value until AFTER you check its validity, and should not continue setting them if they are invalud. This does depend on what the theoretical use of the employee object is, but in general you should adhere to that, unless the assignment says otherwise.

Fourth, I'm not sure why you refactored the check out of the function, but it makes no sense to call it "getException" since that implies an accessor and not a function call, AND because it does not describe what the function is actually doing, which is validating the input.

Fifth, the name of the exception is too vague. You should consider using something like EmployeeInvalidWageException, and your exception probably should have a private field containing the hourly wage, in addition to the standard "message" that an exception ought to have.

 

[Kilrsat]

Originally posted by: jm20
well this is just for a assignment for my java class, and those are the only objects ever being created, as im supposed to create a over, under, and within value to use the exception. Right now I satisfy those

so the lesson here is to try catch in the main while creating the objects to prevent invalid ones from being created ?

The example you're using here the Exception is being used to determine an invalid state of the object. Once the object enters an invalid state, anything that object produces is likewise invalid, you can't trust it, its icky, garbage, etc. In short, bad data leads to more bad data. Simply printing out a message that the data is bad doesn't help. Think if this was at the start of a 10hr batch job, the results would contain a message that says the input was bad, but 10hrs of processing was still completed. Thus leaving you with 10 wasted hours because everything that was computed can't be trusted.

So if you are checking for an invalid state, and you determine that invalid state is about to happen you need to stop and yell at the caller. Telling them simply "hey, that's an illegal object you tried to create, do something about it."

There are other conditions that exceptions can occur which don't call for a dead-stop, and like was noted, location of handling is really done case by case.

 

[MrChad]

Originally posted by: torpid

Originally posted by: jm20
Is this an example of good coding for exception handling ? or should I put the try catch statement in the main method and do them individually.

No. First off your exception message does not contain any useful information. If this were a big project even the developer would have no idea what it means without looking over the stack trace and line numbers.

Secondly, are you sure you are supposed to swallow the exception and not throw it?

Thirdly, you should not be setting the private fields to the value until AFTER you check its validity, and should not continue setting them if they are invalud. This does depend on what the theoretical use of the employee object is, but in general you should adhere to that, unless the assignment says otherwise.

Fourth, I'm not sure why you refactored the check out of the function, but it makes no sense to call it "getException" since that implies an accessor and not a function call, AND because it does not describe what the function is actually doing, which is validating the input.

Fifth, the name of the exception is too vague. You should consider using something like EmployeeInvalidWageException, and your exception probably should have a private field containing the hourly wage, in addition to the standard "message" that an exception ought to have.

Good points. You'll want to do something like this. You'll also want to make EmployeeInvalidWageException contain some more relevant data if you're going to use a custom Exception object.