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
