Thank you for the comments Martin and Stefan. I may try posting this
question on a Java programming forum, but I always like to check here
first.
Martin: I do not know if this error is unique to the Eclipse Compiler.
I haven't compiled it from the command line, so I don't know if this
is an Eclipse problem. I'll try the same code in Netbeans to see if I
get the same error.
Stefan,
I need to think some more about what you said.
Landon
On Jan 29, 2008 1:30 PM, Stefan Steiniger <[EMAIL PROTECTED]> wrote:
>
>
> Sunburned Surveyor schrieb:
> > If I undertstand your suggestion correctly, then the technique you
> > suggest doesn't work, at least not with the Eclipse compiler. If you
> > declare the variable being returned before the try/catch statements,
> > but set the value within the try statement, the Eclipse compiler
> > complains that you could be returning a value that may not be
> > initialized. This means you end up setting the variable you want to
> > return to null before the try statement,
>
> yes
>
> instead of setting it to null
> > after. Either way, the null value will not be returned, and it doesn't
> > matter whether it is set before or after. In essence, the same problem
> > exists.
>
> the null value will be returned, since all arguments after the block
> should be executed.
>
> (but may be remember something wrong)
>
> >
> > Perhaps using your technique makes more sense for someone reading the
> > code, in which case I should adopt it. Still, it would be nice if the
> > Java compiler could recognize that only one of two execution paths are
> > possible with this method. In the first the try statement properly
> > intializes the return value and returns it to the caller, or the catch
> > statement throws the exception. In no execution scenario does a null
> > value need to be returned.
>
> oh.. but what if you want the application should still be continued and
> no message thrown: e.g. If you expect a returned value to be an
> int/double you can set the variable to: "-1" later in in the calling
> function you know when the returned value is "-1" you do some specific
> actions (i.e. derive the expected value with a work around function).
>
>
> >
> > Its almost like the compiler is failing to recognize the exception,
> > and still expects the method to return a value when the exception will
> > be thrown because of error conditions.
> >
> > Maybe I'm missing an obvious part of the picture.
> >
> > The Sunburned Surveyor
> >
> > On Jan 29, 2008 12:28 PM, Stefan Steiniger <[EMAIL PROTECTED]> wrote:
> >> mhm.. I don't realy get why you put the first return into the try case?
> >> why should one return within a function and not at the end of a method?
> >> (i.e. i have never seen this in java code)
> >>
> >> instead declear a new method variable and set their value within try{}
> >> and/or catch{} and return this variable at the end.
> >>
> >> stefan
> >>
> >> Sunburned Surveyor schrieb:
> >>
> >>> I've got a quick question about the best way to handle return values
> >>> in Java methods with a try/catch statement. Consider, as an example,
> >>> the following method:
> >>>
> >>> public static SurveyorsAngle getSupplementaryAngle(SurveyorsAngle
> >>> argAngle)
> >>> {
> >>> try
> >>> {
> >>> SurveyorsAngle halfRevolution = new BasicSurveyorsAngle(0.50);
> >>> SurveyorsAngle toReturn =
> >>> AngleCruncher.subtractAngles(halfRevolution, argAngle);
> >>> return toReturn;
> >>> }
> >>>
> >>> catch(ShouldNeverReachHere caught)
> >>> {
> >>> System.err.println(caught.getMessage());
> >>> }
> >>>
> >>> return null;
> >>> }
> >>>
> >>> In this example the return value must be set within the try statement,
> >>> becuase the subtractAngles method throws an exception.
> >>>
> >>> This means that the method has to return a null value after the
> >>> try/catch statements. However, this return statement will never be
> >>> reached, because the method will either [1] return from the try
> >>> statement with a valid SurveyorsAngle object or [2] execution will
> >>> shift to the catch statement.
> >>>
> >>> However, if I remove the return null statement from the end of this
> >>> method, Eclipse gives me a compile error. This error states that the
> >>> getSupplementaryAngle method must return a SurveyorsAngle value.
> >>>
> >>> I seem to run into this a lot in my code. I know I could just
> >>> eiliminate the try/catch statement and add a throws clause to the
> >>> containing method, but sometimes the exception SHOULD be handled in
> >>> the containing method.
> >>>
> >>> Is there a better solution? It seems like the compiler is requiring a
> >>> return statement that can never be reached.
> >>>
> >>> Thanks for any advice on this.
> >>>
> >>> The Sunburned Surveyor
> >>>
> >>> -------------------------------------------------------------------------
> >>> This SF.net email is sponsored by: Microsoft
> >>> Defy all challenges. Microsoft(R) Visual Studio 2008.
> >>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> >>> _______________________________________________
> >>> Jump-pilot-devel mailing list
> >>> Jump-pilot-devel@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> >>>
> >>>
> >> -------------------------------------------------------------------------
> >> This SF.net email is sponsored by: Microsoft
> >> Defy all challenges. Microsoft(R) Visual Studio 2008.
> >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> >> _______________________________________________
> >> Jump-pilot-devel mailing list
> >> Jump-pilot-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> >>
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Jump-pilot-devel mailing list
> > Jump-pilot-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> >
> >
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
