Hi Landon,
Unless I'm misunderstanding, the behavior of the compiler seems normal to me.
>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.
The catch statement has "caught" the exception, so execution proceeds
to the next statement after the catch block. This problem only occurs
if you don't use the catch block to throw a exception to the caller.
In other words, if it is proper and necessary to throw the exception
in AngleCruncher.subtractAngles(), then it is probably a bad idea to
simply eat the exception here and just log it to the err console.
My recommendation would be to have the function throw the exception by
declaring it as getSupplementaryAngle(..) throws ShouldNeverReachHere
{... Then you can remove the try catch blocks and just code
normally.
regards,
Larry
On Jan 29, 2008 4:58 PM, Sunburned Surveyor
<[EMAIL PROTECTED]> wrote:
> 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
>
--
http://amusingprogrammer.blogspot.com/
-------------------------------------------------------------------------
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
