I may be wrong, and I'm too lazy to actually test it,
but I think the last "return null" is indeed reached.

The catch kind of "kills" the exception, it eats it up,
so, with the exception gone, execution resumes right after
the catch block, and the "return null" _is_ reached.

That's why the compiler complains if you remove it.

Bye
Paolo Rizzi


> -----Messaggio originale-----
> Da: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] conto di
> Sunburned Surveyor
> Inviato: martedì 29 gennaio 2008 21.20
> A: List for discussion of JPP development and use.
> Oggetto: [JPP-Devel] [Off-Topic] Return values in Java methods with
> atry/catch statements.
> 
> 
> 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

Reply via email to