Thanks to everyone's comments, especially Joe's and Larry's, I now
understand the error of my ways. What makes this code different from
the other code I'm used to working with in OpenJUMP is that this code
is part of a library. In this case I'm trying to handle the exception
within the library. This is not appropriate. I need to throw this
exception from the method and let the caller of the libraries API
decide how to handle the exception.
It seems, as a general rule, that library should delegate exception
handling to client code in most cases. I will modify the JTSWarped
code to reflect this.
Part of my confusion was the result of my believing that the catch
statement halted execution of the program, which I realize now it does
not.
Thanks for all of the help. I know I'm only a hobby programmer, but
I'm always surprised at how much I have to learn about the one
porgamming language I use the most.
The Sunburned Surveyor
On Jan 30, 2008 8:22 AM, Larry Becker <[EMAIL PROTECTED]> wrote:
> 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
>
-------------------------------------------------------------------------
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
