Thread overview | ||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
July 20, 2004 return and throw | ||||
---|---|---|---|---|
| ||||
Trimmed this one down to the absolute minimum # int f() # { # throw new Error(""); # } Currently this is a compile error: auto.d(2): function f function expected to return a value of type int But it shouldn't be (and wouldn't be in C++). The function should only be "expected to return a value of type int" /if it actually returns/. If you exit via an exception, you don't need to return anything. Arcane Jill |
July 20, 2004 Re: return and throw | ||||
---|---|---|---|---|
| ||||
Posted in reply to Arcane Jill | On Tue, 20 Jul 2004 07:39:38 +0000 (UTC), Arcane Jill wrote: > Trimmed this one down to the absolute minimum > > # int f() > # { > # throw new Error(""); > # } > > Currently this is a compile error: > auto.d(2): function f function expected to return a value of type int > > But it shouldn't be (and wouldn't be in C++). The function should only be "expected to return a value of type int" /if it actually returns/. If you exit via an exception, you don't need to return anything. > > Arcane Jill Jill, this is just silly. If one is going to write a routine that ... (a) says it will return something "int f()", and (b) deliberately *never* returns something, then you just have to wear the compiler message. -- Derek Melbourne, Australia 20/Jul/04 6:05:28 PM |
July 20, 2004 Re: return and throw | ||||
---|---|---|---|---|
| ||||
Posted in reply to Derek Parnell | "Derek Parnell" <derek@psych.ward> wrote in message news:cdik17$18ej$1@digitaldaemon.com... > On Tue, 20 Jul 2004 07:39:38 +0000 (UTC), Arcane Jill wrote: > > > Trimmed this one down to the absolute minimum > > > > # int f() > > # { > > # throw new Error(""); > > # } > > > > Currently this is a compile error: > > auto.d(2): function f function expected to return a value of type int > > > > But it shouldn't be (and wouldn't be in C++). The function should only be > > "expected to return a value of type int" /if it actually returns/. If you exit > > via an exception, you don't need to return anything. > > > > Arcane Jill > > Jill, this is just silly. If one is going to write a routine that ... > > (a) says it will return something "int f()", and > (b) deliberately *never* returns something, > > then you just have to wear the compiler message. Although I think Dereks' being simplistic - since after all one might write a function such as that shown below - I still agree with his sentiment. I never write code that precipitates such responses from the compiler, and voila, I never get those responses. Now I'm not saying you're wrong, but I think issues such as this should be on the back of the queue. A less dismissable example would be as follows: double sqrt(double d) { if(d >= 0) { return . . .; } throw Error(); } I'd never write this code, since I'd always want to explicitly deal with the erroneous parameters first, and I'd suggest that's a better style all round. |
July 20, 2004 Re: return and throw | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matthew | As much as it pains me :) I have to agree with Matthew. There's a whole list of other stuff to get working properly before this could be upgraded from 'niggle' to 'issue'. |
July 20, 2004 Re: return and throw | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matthew | On Tue, 20 Jul 2004 18:17:28 +1000, Matthew wrote: > "Derek Parnell" <derek@psych.ward> wrote in message news:cdik17$18ej$1@digitaldaemon.com... >> On Tue, 20 Jul 2004 07:39:38 +0000 (UTC), Arcane Jill wrote: >> >>> Trimmed this one down to the absolute minimum >>> >>> # int f() >>> # { >>> # throw new Error(""); >>> # } >>> >>> Currently this is a compile error: >>> auto.d(2): function f function expected to return a value of type int >>> >>> But it shouldn't be (and wouldn't be in C++). The function should only > be >>> "expected to return a value of type int" /if it actually returns/. If > you exit >>> via an exception, you don't need to return anything. >>> >>> Arcane Jill >> >> Jill, this is just silly. If one is going to write a routine that ... >> >> (a) says it will return something "int f()", and >> (b) deliberately *never* returns something, >> >> then you just have to wear the compiler message. > > Although I think Dereks' being simplistic - since after all one might write a function such as that shown below - I still agree with his sentiment. I never write code that precipitates such responses from the compiler, and voila, I never get those responses. Now I'm not saying you're wrong, but I think issues such as this should be on the back of the queue. > > A less dismissable example would be as follows: > > double sqrt(double d) > { > if(d >= 0) > { > return . . .; > } > > throw Error(); > } > > I'd never write this code, since I'd always want to explicitly deal with the erroneous parameters first, and I'd suggest that's a better style all round. Actually, your code will compile (once the syntax is cleaned up). What I meant by " *never* returns something" was that under no circumstance will the routine ever return a value. In your example, it will return a value under some circumstances, but Jill's example will literally never return anything. That is the silly part. Either declare "void f()..." or give it some chance of returning a value (at least as far as the compiler is concerned). -- Derek Melbourne, Australia 20/Jul/04 6:23:41 PM |
July 20, 2004 Re: return and throw | ||||
---|---|---|---|---|
| ||||
Posted in reply to Derek Parnell | In article <cdik17$18ej$1@digitaldaemon.com>, Derek Parnell says... >Jill, this is just silly. If one is going to write a routine that ... > >(a) says it will return something "int f()", and >(b) deliberately *never* returns something, > >then you just have to wear the compiler message. <Sigh>. Well, so much for paring things down to the absolute minimum. Okay then, a slightly longer example: # class A # { # override int opCmp(Object o) # { # assert(false); // class A not comparable # } # } You don't have much choice about declaring a return type, because that's declared in the base class and you want the polymorphism to work. Jill PS. In the above example, the assert disappears in a release build, giving a different flow of execution (and a genuine compile error) from that of a debug build. Using throw gives a consistent flow of execution. |
July 20, 2004 Re: return and throw | ||||
---|---|---|---|---|
| ||||
Posted in reply to Derek Parnell | Derek Parnell wrote:
> Jill, this is just silly. If one is going to write a routine that ...
>
> (a) says it will return something "int f()", and
> (b) deliberately *never* returns something,
>
> then you just have to wear the compiler message.
Back down to reality, it's a useful idiom for stub methods and the like. Besides, programmer time can be used for better things than writing code that can never be executed just to make the compiler happy.
-- andy
|
July 20, 2004 Re: return and throw | ||||
---|---|---|---|---|
| ||||
Posted in reply to Arcane Jill | On Tue, 20 Jul 2004 08:52:32 +0000 (UTC), Arcane Jill wrote: > In article <cdik17$18ej$1@digitaldaemon.com>, Derek Parnell says... >>Jill, this is just silly. If one is going to write a routine that ... >> >>(a) says it will return something "int f()", and >>(b) deliberately *never* returns something, >> >>then you just have to wear the compiler message. > > <Sigh>. Well, so much for paring things down to the absolute minimum. Okay then, a slightly longer example: > > # class A > # { > # override int opCmp(Object o) > # { > # assert(false); // class A not comparable > # } > # } > > You don't have much choice about declaring a return type, because that's declared in the base class and you want the polymorphism to work. > > Jill > > PS. In the above example, the assert disappears in a release build, giving a different flow of execution (and a genuine compile error) from that of a debug build. Using throw gives a consistent flow of execution. Ok, we have a different coding style. I would have done something like this... # class A # { # override int opCmp(Object o) # { # assert(false); // class A not comparable # throw new Error("class A not comparable"); # return 0; # } # } -- Derek Melbourne, Australia 20/Jul/04 7:17:57 PM |
July 20, 2004 Re: return and throw | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andy Friesen | On Tue, 20 Jul 2004 01:58:42 -0700, Andy Friesen wrote: > Derek Parnell wrote: >> Jill, this is just silly. If one is going to write a routine that ... >> >> (a) says it will return something "int f()", and >> (b) deliberately *never* returns something, >> >> then you just have to wear the compiler message. > > Back down to reality, it's a useful idiom for stub methods and the like. > Besides, programmer time can be used for better things than writing > code that can never be executed just to make the compiler happy. > > -- andy Ain't that the truth! However back at Reality Base, we still gotta keep the compiler happy ;-) -- Derek Melbourne, Australia 20/Jul/04 7:19:29 PM |
July 20, 2004 Statements following return, throw, etc.. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Derek Parnell | In article <cdio37$1a87$1@digitaldaemon.com>, Derek Parnell says... >Ok, we have a different coding style. I would have done something like this... > ># class A ># { ># override int opCmp(Object o) ># { ># assert(false); // class A not comparable ># throw new Error("class A not comparable"); ># return 0; ># } ># } Well, I would certainly argue that is (or should be) an error to place any statement immediately after a throw, (that is, between throw and end-of-scope) because such statements will never be executed. This would certainly be an error in most other languages which have exception throwing. So your workaround would itself be a compile error in C++, and would be in D, too, if D behaved similarly (which I think it should). In a similar vein, the following compiles successfully in D: # int main() # { # return 1; # return 2; # } Even my Commodore Amiga C compiler back in 1985 would have spotted that one. Arcane Jill |
Copyright © 1999-2021 by the D Language Foundation