On Wednesday, 12 June 2013 at 21:34:31 UTC, Andrej Mitrovic wrote:
> I thought doing this only for function definitions could make sense.
> For declarations the user would have to do it manually.

Yeah, it'd still be somewhat imprecise though because bar() would also 'throw' whatever foo() can throw too. (And if foo() is private there may be no documentation to check, either.)

But it could still probably do a pretty good job, might be worth looking into.

Ary Borenszweig:

>> Maybe checked exceptions are bad only for the type system of Java. Maybe
>> for a language that has global type inferencing on the exceptions such
>> feature becomes better.
>
> Why?

I am not an expert of type systems, so this is this just an hypothesis. What are the disadvantages of checked exceptions? One problem is that those annotations are heavy, make the code rigid to change, and this doesn't go well with normal programmer laziness. A global type inferencer (that doesn't work well with the dynamic nature of Java) avoids the need for all exception annotations, but forces you to catch exceptions somewhere, assuring no holes remain if you don't want holes.

Bye,
bearophile

On 6/12/13 6:49 PM, bearophile wrote:
> Ary Borenszweig:
>
>>> Maybe checked exceptions are bad only for the type system of Java. Maybe
>>> for a language that has global type inferencing on the exceptions such
>>> feature becomes better.
>>
>> Why?
>
> I am not an expert of type systems, so this is this just an hypothesis.
> What are the disadvantages of checked exceptions? One problem is that
> those annotations are heavy, make the code rigid to change, and this
> doesn't go well with normal programmer laziness. A global type
> inferencer (that doesn't work well with the dynamic nature of Java)
> avoids the need for all exception annotations, but forces you to catch
> exceptions somewhere, assuring no holes remain if you don't want holes.
>
> Bye,
> bearophile

But if a type checker deduces a function foo throws exception A, and in function bar you call foo: are you forced to handle the exception? If not, do you have to tell the compiler that you don't want to handle that exception? Isn't that the same as what Java does?

Ary Borenszweig:

> But if a type checker deduces a function foo throws exception A, and in function bar you call foo: are you forced to handle the exception? If not, do you have to tell the compiler that you don't want to handle that exception? Isn't that the same as what Java does?

Let's keep playing :-)

- I think if you don't want to handle the exception, you don't handle the exception, and the type system assumes you will handle the exception at a higher level.
- In every point of the program you can also ask to the type system (like through the IDE) what are the current exceptions that can happen there.
- If you don't handle exceptions in the main, your program will throw them. If you annotate a function with nothrow then the type system forces you to handle all the possible exceptions of that function inside the function.

Bye,
bearophile

On Wednesday, June 12, 2013 23:33:31 Timon Gehr wrote:
> > C++98 had checked exceptions (exception specifications), too. Another failure of the idea, it failed so badly hardly anyone but language lawyers ever knew it had it.
> 
> Weren't those checked at runtime?

Yes. If another exception type was thrown, it called something like unexpected_exception (I don't remember the exact function) which called abort by default and killed your program. So, while Java's checked are ultimately a bad idea, they at least have _some_ redeeming value, whereas C++ throw specifiers really don't.

- Jonathan M Davis

On 6/12/2013 2:49 PM, bearophile wrote:
> What are the disadvantages of checked exceptions?

See the link to Bruce Eckel's article I posted in this thread.

Walter Bright:

> See the link to Bruce Eckel's article I posted in this thread.

Mine was a rhetorical question :-)

Bye,
bearophile

On Wednesday, 12 June 2013 at 12:50:39 UTC, Andrei Alexandrescu wrote:
> Reddit: http://www.reddit.com/r/programming/comments/1g6x9g/dconf_2013_code_analysis_for_d_with_analyzed/
>
> Hackernews: https://news.ycombinator.com/item?id=5867764
>
> Twitter: https://twitter.com/D_Programming/status/344798127775182849
>
> Facebook: https://www.facebook.com/dlang.org/posts/655927124420972
>
> Youtube: http://youtube.com/watch?v=ph_uU7_QGY0
>
> Please drive discussions on the social channels, they help D a lot.
>
>
> Andrei

He mentions a D plug-in for sonar.
Is this available publicly?

Adam D. Ruppe:

> These are pretty easy to add to dmd. In doc.c's FuncDelaration::toDocBuffer you can throw in something like this:
>             if(frequire)
>                 buf->writestring(frequire->toChars());
>             if(fensure)
>                 buf->writestring(fensure->toChars());
>
> with a little cleanup and a wrapper macro and I think that would be good.

Maybe with a compiler switch syntax like:

-D:+-switch1,...,+-switchn

Using a command like?

-D:+contracts

Bye,
bearophile

On 2013-06-12 19:31, bearophile wrote:

> How to annotate throws in ddoct? Do they need to be generated
> automatically?

That would be nice. Possibly a macro the compiler knows about so you can place it anywhere you want. Or a way to opt it out.

> Regarding pre/post conditions, maybe a ddoc macro or switch can be used
> to make them appear in the ddoc output on request.

Wouldn't mind having that.

> I think the built-in unit test system should be improved, so in _most_
> cases there's no need to use a second unittest system.

I agree. But there's a conflict of interest here. Some people like output when the tests are running (I do), some don't. Walter likes the simplicity of the unit test system.

-- 
/Jacob Carlborg