www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - return and throw

reply Arcane Jill <Arcane_member pathlink.com> writes:
Trimmed this one down to the absolute minimum






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
Jul 20 2004
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 20 Jul 2004 07:39:38 +0000 (UTC), Arcane Jill wrote:


 Trimmed this one down to the absolute minimum
 




 
 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
Jul 20 2004
next sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"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






 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.
Jul 20 2004
next sibling parent reply Cabal <cabalN05P4M myrealbox.com> writes:
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'.
Jul 20 2004
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"Cabal" <cabalN05P4M myrealbox.com> wrote in message
news:cdiklu$18c7$1 digitaldaemon.com...

 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'.


So you're not going to be fighting through the crowds in the bookshop in
September?

Sigh, I'll have to ring AWL and tell them to cut down the print run.
Jul 20 2004
parent reply Cabal <cabalN05P4M myrealbox.com> writes:
Christ no! I'll buy the other 50% of the run :) 
When you aren't being all religious you seem to know a fair old bit about
D...


 So you're not going to be fighting through the crowds in the bookshop in
 September?
 
 Sigh, I'll have to ring AWL and tell them to cut down the print run.
Jul 20 2004
parent "Matthew" <admin.hat stlsoft.dot.org> writes:
You're just trying to be nice to me, now.

I don't think it suits either of us. ;)

"Cabal" <cabalN05P4M myrealbox.com> wrote in message
news:cdj4to$1fqh$1 digitaldaemon.com...

 Christ no! I'll buy the other 50% of the run :)
 When you aren't being all religious you seem to know a fair old bit about
 D...


 So you're not going to be fighting through the crowds in the bookshop in
 September?

 Sigh, I'll have to ring AWL and tell them to cut down the print run.
Jul 20 2004
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
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






 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
Jul 20 2004
parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:cdil05$18sv$1 digitaldaemon.com...

 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






 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.


I knew what you meant. :)
Jul 20 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:cdikf7$18m6$1 digitaldaemon.com...

 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.


I don't agree one might never write such a function. I'll do it sometimes to
fill in stubs that I intend to work on later, and the exception thrown will
remind me if I forget. I'll also do it to fill in stubs required by
something else, but that I know will never actually be called. (Such as
putting a stub implementation for an abstract function required by an
interface, but which would be an error for your circumstances.)
Jul 20 2004
parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:cdjo8s$1p14$2 digitaldaemon.com...

 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 news:cdikf7$18m6$1 digitaldaemon.com...

 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.


 I don't agree one might never write such a function. I'll do it sometimes to
 fill in stubs that I intend to work on later, and the exception thrown will
 remind me if I forget. I'll also do it to fill in stubs required by
 something else, but that I know will never actually be called. (Such as
 putting a stub implementation for an abstract function required by an
 interface, but which would be an error for your circumstances.)


What, old buddy? We're disagreeing! Say it ain't so.

Will it be two books, in one? A psychotic spawn with a split personality. :-)
Jul 20 2004
prev sibling next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
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:









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.
Jul 20 2004
parent reply Derek Parnell <derek psych.ward> writes:
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:
 







 
 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...











-- 
Derek
Melbourne, Australia
20/Jul/04 7:17:57 PM
Jul 20 2004
next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <cdio37$1a87$1 digitaldaemon.com>, Derek Parnell says...


Ok, we have a different coding style. I would have done something like
this...












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:







Even my Commodore Amiga C compiler back in 1985 would have spotted that one.

Arcane Jill
Jul 20 2004
parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <cditbh$1c4m$1 digitaldaemon.com>, Arcane Jill says...

Only in D could you do this!







Jill

(PS. This is a minimal code example. Actual bugs in real code would obviously be
more complicated than this).
Jul 20 2004
next sibling parent reply Takuan <Takuan_member pathlink.com> writes:
In article <cditku$1cah$1 digitaldaemon.com>, Arcane Jill says...

In article <cditbh$1c4m$1 digitaldaemon.com>, Arcane Jill says...

Only in D could you do this!







Jill

(PS. This is a minimal code example. Actual bugs in real code would obviously be
more complicated than this).


Calm down, Jill. This is not exactly a bug. Typical C/C++ compiler would issue a
warning saying "Unreachable code" in this case or "Not all control paths return
a value" in your previous example. Fixing this kind of behaviour now
is not really needed, while there are lots of other (serious) bugs floating
around.

P.S. Never had bugs in code because of misplaced return. Dunno why...
Jul 20 2004
next sibling parent "Ivan Senji" <ivan.senji public.srce.hr> writes:
"Takuan" <Takuan_member pathlink.com> wrote in message
news:cdj0cg$1dcj$1 digitaldaemon.com...

 In article <cditku$1cah$1 digitaldaemon.com>, Arcane Jill says...

In article <cditbh$1c4m$1 digitaldaemon.com>, Arcane Jill says...

Only in D could you do this!







Jill

(PS. This is a minimal code example. Actual bugs in real code would




obviously be

more complicated than this).


 Calm down, Jill. This is not exactly a bug. Typical C/C++ compiler would


issue a

 warning saying "Unreachable code" in this case or "Not all control paths


return

 a value" in your previous example. Fixing this kind of behaviour now
 is not really needed, while there are lots of other (serious) bugs


floating

 around.

 P.S. Never had bugs in code because of misplaced return. Dunno why...


I had such a bug, and it wasn't that easy to find it!

I agree with Arcane Jill, Code after return or throw in a block should
be an error, but there is time for this, because there are more important
open ishues!
Jul 20 2004
prev sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <cdj0cg$1dcj$1 digitaldaemon.com>, Takuan says...


Calm down, Jill.


I've been calm all along, thank you very much, and it is perhaps a little
disingenuous of you to imply otherwise.



This is not exactly a bug. Typical C/C++ compiler would issue a
warning saying "Unreachable code" in this case or "Not all control paths return
a value" in your previous example.


Fair enough. Guess I've been using "treat warnings as errors" for too long.



Fixing this kind of behaviour now
is not really needed, while there are lots of other (serious) bugs floating
around.


I agree. However, I find the comment irrelevant. If I have understood you
correctly.... we shouldn't post bugs here which are less serious than those
already in the queue. Is that right?

I'm sure Walter would prefer that they be reported than not, even if they are
trivial, and that the bugs forum is the correct place to report them. I'm not
aware of a dictat that says "don't report low priority bugs". Do correct me if
I'm wrong.

Jill
Jul 20 2004
parent J Anderson <REMOVEanderson badmama.com.au> writes:
Arcane Jill wrote:


In article <cdj0cg$1dcj$1 digitaldaemon.com>, Takuan says...

  


Calm down, Jill.
    


I've been calm all along, thank you very much, and it is perhaps a little
disingenuous of you to imply otherwise.


  


This is not exactly a bug. Typical C/C++ compiler would issue a
warning saying "Unreachable code" in this case or "Not all control paths return
a value" in your previous example.
    


Fair enough. Guess I've been using "treat warnings as errors" for too long.


  


Fixing this kind of behaviour now
is not really needed, while there are lots of other (serious) bugs floating
around.
    


I agree. However, I find the comment irrelevant. If I have understood you
correctly.... we shouldn't post bugs here which are less serious than those
already in the queue. Is that right?

I'm sure Walter would prefer that they be reported than not, even if they are
trivial, and that the bugs forum is the correct place to report them. I'm not
aware of a dictat that says "don't report low priority bugs". Do correct me if
I'm wrong.

Jill

  


I think the argument here is that this type of problem is something that 
can easily be added at anytime, and has is essentially a semantic bug.   
Syntactical bugs that cause dmd to not finish or cause the program to 
crash (directly) are probably seen as more trouble some since people 
have already learned to live with this in C++.

No harm ins suggesting it.  That's what the D newsgroups are for.  I see 
this as more of a feature request (ie for more strict syntax) rather 
then a bug which is kinda the other groups realm.  I agree that more C++ 
warnings should be made into D errors.


-- 
-Anderson: http://badmama.com.au/~anderson/
Jul 20 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:cditku$1cah$1 digitaldaemon.com...

 In article <cditbh$1c4m$1 digitaldaemon.com>, Arcane Jill says...

 Only in D could you do this!








This is allowed in D (and in C, C++) because it comes in handy when
debugging code. For example, I may wish in the process of isolating down a
bug to just 'stub out' a function by putting in a return as the first
statement. I do this stuff all the time.

I'll also do things like force a particular branch to happen by changing:
    if (x) { ... } else { ... }
to:
    if (1 || x) { ... } else { ... }
or:
    if (0 && x) { ... } else { ... }

The optimizer will remove any dead code.
Jul 20 2004
parent J Anderson <REMOVEanderson badmama.com.au> writes:
Walter wrote:


"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:cditku$1cah$1 digitaldaemon.com...
  


In article <cditbh$1c4m$1 digitaldaemon.com>, Arcane Jill says...

Only in D could you do this!






    


This is allowed in D (and in C, C++) because it comes in handy when
debugging code. For example, I may wish in the process of isolating down a
bug to just 'stub out' a function by putting in a return as the first
statement. I do this stuff all the time.

I'll also do things like force a particular branch to happen by changing:
    if (x) { ... } else { ... }
to:
    if (1 || x) { ... } else { ... }
or:
    if (0 && x) { ... } else { ... }

The optimizer will remove any dead code.

  


But we now have nested comments.  Almost defeats that purpose doesn't it?


-- 
-Anderson: http://badmama.com.au/~anderson/
Jul 21 2004
prev sibling parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:cdio37$1a87$1 digitaldaemon.com...

 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:









 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...












That's a lot more obvious, and maintainable.
Jul 20 2004
prev sibling parent reply Andy Friesen <andy ikagames.com> writes:
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
Jul 20 2004
parent Derek Parnell <derek psych.ward> writes:
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
Jul 20 2004
prev sibling parent reply J C Calvarese <jcc7 cox.net> writes:
In article <cdii7q$17p3$1 digitaldaemon.com>, Arcane Jill says...

Trimmed this one down to the absolute minimum






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


(I'm trying to be helpful. Really, I am.)

The reason why people might want to comment on this "bug report" is that the
compiler is enforcing the specification:

"At least one return statement is required if the function specifies a return
type that is not void." (http://www.digitalmars.com/d/statement.html#return)

If the compiler is following the spec, it seems more like a *feature request*
than a bug. I think if you want to discuss this issue, it should be in the
digitalmars.D group. Feel free to disagree. Discuss it in the D.gnu group or
digitalmars.D.dtl if you like. Whatever. It's your decision.

jcc7
Jul 20 2004
parent reply "Bent Rasmussen" <exo bent-rasmussen.info> writes:
Then where does one post specification bugs? :-)
Jul 20 2004
parent reply J C Calvarese <jcc7 cox.net> writes:
In article <cdjc7b$1jfu$1 digitaldaemon.com>, Bent Rasmussen says...

Then where does one post specification bugs? :-)


I'm not sure if that's meant to be a rhetorical question, but I'll try to
respond anyway. 

My opinion: it depends on what you mean by "specification bugs".

Here's some proposed guidelines...

Post to dm.D.bugs
-----------------
if you find a possible typographical error in the spec
if the compiler doesn't follow the spec
if the compiler produces a confusing or incorrect error message
if the compiler crashes without even producing an error message
if the compiler produces an executable that behaves unexpectedly
(This list isn't all-inclusive.)


Post to dm.D
------------
if you want to change the spec significantly (yes, it's a judgment call)
if you don't understand an idea in the spec
if you don't like an idea in the spec 
if you think the spec needs more examples
if you think the spec is incomplete (unless you think it's really, really
incompelte)
if a thread in dm.D.bugs drifts like this one has into broader concepts (oops)
(This list definitely isn't all-inclusive.)


No one has to agree with me on any of these, but this is how I try to decide
where to post. Until I realize I'm posting in the wrong place.

By the way, for a long time I was opposed to having separate newsgroups because
I didn't want to read a bunch of bickering about which threads belong in which
newsgroups. Polite comments and discussions about the topic are appropriate (how
else could we reach consensus?), but posting "WRONG NEWSGROUP, STUPID" would be
bad. I hope we can remember how these newsgroups used to be more civil. Ah, the
good old days...

jcc7
Jul 20 2004
parent "Bent Rasmussen" <exo bent-rasmussen.info> writes:
I use two guidelines: common sense and politeness, the rest is implicit.
Jul 20 2004