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

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

 #    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


 "expected to return a value of type int" /if it actually returns/. If


 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

 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

 #    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


 "expected to return a value of type int" /if it actually returns/. If


 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

 #    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


 "expected to return a value of type int" /if it actually returns/. If


 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


 a function such as that shown below - I still agree with his sentiment.


 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


 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


 erroneous parameters first, and I'd suggest that's a better style all


 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

 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

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

# 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
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!

#    void main()
#    {
#        return;
#        printf("hello world\n");
#    }

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!

#    void main()
#    {
#        return;
#        printf("hello world\n");
#    }

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!

#    void main()
#    {
#        return;
#        printf("hello world\n");
#    }

Jill

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


more complicated than this).

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

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

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

 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!

 #    void main()
 #    {
 #        return;
 #        printf("hello world\n");
 #    }

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!

#    void main()
#    {
#        return;
#        printf("hello world\n");
#    }
    

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.


 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,


 different flow of execution (and a genuine compile error) from that of a


 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; # } # }

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

#    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

(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