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

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

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

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

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

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.

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

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

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

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