Re: [returning error message on abort]how to interrupt normal process
in a method
Daniel Moyne wrote:
Lew,
great it works ; I just replaced "this(message)" by "this.message=message"
to recover my string message and added "private String message" ; maybe
The parent class already handles messages. You do not need to declare your
own. That is why I used the constructor to set the message, not an assignment.
rather than collecting a string I will collect an int errorNumber and
decode this in the catch {} section to display the error message
accordingly but this will make my code not very clear to read ; I will see
A few questions :
- why do you have to declare indi (and message) as private,
indi was declared private because that is the safest; it prevent other classes
from modifying the value.
You do not need to declare a message member at all, not even a private one.
The message is inherited.
- why do we have to set this :
public ClassNameMissingException(String message) {
super(message);
}
This is a standard idiom. It lets the child class, ClassNameMissingException,
use the message from the parent class, Exception.
- I do not need here setIndi(Indi indi) as here I wait for the error to
pop-up to collect the indi same for the message string ; as a matter of
fact I am wondering where this could be used in an exception process :
I'm afraid you lost me there.
(a) inside this catch section :
catch(ClassNameMissingException errorVariable) {
//decide what to do here, usually a good thing is..
errorVariable.printStackTrace();
println(errorVariable.getErrorMessage()+errorVariable.getErrorIndi());
}
no use !
(b) outside this catch section :
I have no object to apply setIndi(indi) to !!!!!
You wouldn't set Exception attributes in the catch block but just prior to the
"throw" of your exception. It is the "throw" that gives you all that lovely
stack trace information, too.
- was this exception procees the best compromise to combine abortion and
comprehensive error message related to the location where the error was
enforced
I am not sure I fully grok you here, either, but I think you are asking if
Exceptions are the optimal means to handle exceptional circumstances. I would
have to say that they are, until something better comes along. I don't see
much in the way of compromise there, either.
(here not error system but user errors).
Do you mean "system errors" versus "user errors"? Exceptions are good for both
types of things, but not when you want to continue processing. They are good
for graceful recovery and restart. Many kinds of "errors" can be handled by
giving a default value, or by having the user re-enter some information, and
would not require Exceptions.
I strongly suggest that you work through the Sun Java tutorials, and Bruce
Eckel's book _Thinking in Java_ is an excellent resource, too.
http://www.mindview.net/Books/TIJ/
Your practical work on Exceptions is giving you a good start, but reading
these types of things will strengthen your coding greatly.
- Lew