August 13, 2012
On 2012-08-13 12:31, Regan Heath wrote:

> I wonder if it might be possible to make an intellisense style GUI/IDE
> tool/plugin which could determine all exceptions thrown either by direct
> code inspection or ddoc inspection (when source is unavailable) such
> that it could actually build a complete list. It would need to cache
> results in order to be anywhere near performant I reckon.

I think that would be great and possible, at lest to some extent. There's always problems with unknown subclasses, dynamically loaded code and so on.

-- 
/Jacob Carlborg
August 13, 2012
On 12-Aug-12 07:02, Marco Leise wrote:
> I just got a bit frustrated and wanted to say that I like working with Exceptions in Java a lot more.
That has to do first but not foremost with the declaration:
>
> ---Java->>
>
> class MyException extends Exception {
>    public MyException(String msg) {
>      super(msg);
>    }
>    public MyException(String msg, Throwable next) {
>      super(msg, next)
>    }
> }
>
> <<-Java---

I think the true cryptonite that melts "checked exceptions" to a pile of green goo is templated code:

So (*yawn*) tell what kind of exception specification the following function should have:

auto joiner(RoR, Separator)(RoR r, Separator sep);

How would you guarantee upfront what kind of exceptions it can throw is beyond me. It all depends on code that you can't reach or know by the very definition of template.

Back to Java: what is I find strange is the lack of sensible tools to do transactional or exception safe code within the language. No RAII objects or just at least any kludge to reliably register cleanup/rollback, only "good" old try/finally.

-- 
Dmitry Olshansky
August 13, 2012
On 08/13/2012 05:32 PM, Dmitry Olshansky wrote:
>
> I think the true cryptonite that melts "checked exceptions" to a pile of
> green goo is templated code:
>
> So (*yawn*) tell what kind of exception specification the following
> function should have:
>
> auto joiner(RoR, Separator)(RoR r, Separator sep);
>
> How would you guarantee upfront what kind of exceptions it can throw is
> beyond me. It all depends on code that you can't reach or know by the
> very definition of template.
>

Well, presumably the exception specification would be inferred automatically for templates.

August 13, 2012
On 13-Aug-12 19:50, Timon Gehr wrote:
> On 08/13/2012 05:32 PM, Dmitry Olshansky wrote:
>>
>> I think the true cryptonite that melts "checked exceptions" to a pile of
>> green goo is templated code:
>>
>> So (*yawn*) tell what kind of exception specification the following
>> function should have:
>>
>> auto joiner(RoR, Separator)(RoR r, Separator sep);
>>
>> How would you guarantee upfront what kind of exceptions it can throw is
>> beyond me. It all depends on code that you can't reach or know by the
>> very definition of template.
>>
>
> Well, presumably the exception specification would be inferred
> automatically for templates.

What's the propose then? And how end user will get any idea what to put in his function where he uses it? I see one, but it's not pretty - run compiler once - see complaints, add requested types to throws, re-run the compiler?

-- 
Dmitry Olshansky
August 13, 2012
On 08/13/2012 05:54 PM, Dmitry Olshansky wrote:
> On 13-Aug-12 19:50, Timon Gehr wrote:
>> On 08/13/2012 05:32 PM, Dmitry Olshansky wrote:
>>>
>>> I think the true cryptonite that melts "checked exceptions" to a pile of
>>> green goo is templated code:
>>>
>>> So (*yawn*) tell what kind of exception specification the following
>>> function should have:
>>>
>>> auto joiner(RoR, Separator)(RoR r, Separator sep);
>>>
>>> How would you guarantee upfront what kind of exceptions it can throw is
>>> beyond me. It all depends on code that you can't reach or know by the
>>> very definition of template.
>>>
>>
>> Well, presumably the exception specification would be inferred
>> automatically for templates.
>
> What's the propose then?

The same as the OT describes. Don't get me wrong, I am certainly no
proponent of adding Java-style checked exceptions to D.

> And how end user will get any idea what to put
> in his function where he uses it?

The end user is aware of what the template arguments are.

> I see one, but it's not pretty - run compiler once - see complaints,
> add requested types to throws, re-run the compiler?
>

Either add requested types to throws or catch and handle the respective
exceptions. I assume that this is basically the entire point of
statically checked exception specifications.
August 13, 2012
On Monday, 13 August 2012 at 10:02:23 UTC, Marco Leise wrote:
> Thoughts ?

I like this idea - you can use checked exceptions, but you aren't forced.

Though I think private and free functions should by default just use @throws(Exception). Not using @throws is like saying "I don't pay attention to what errors might occur, a new version might be different."

NMS
August 13, 2012
Am Mon, 13 Aug 2012 19:54:47 +0400
schrieb Dmitry Olshansky <dmitry.olsh@gmail.com>:

> On 13-Aug-12 19:50, Timon Gehr wrote:
> > On 08/13/2012 05:32 PM, Dmitry Olshansky wrote:
> >>
> >> I think the true cryptonite that melts "checked exceptions" to a pile of green goo is templated code:
> >>
> >> So (*yawn*) tell what kind of exception specification the following
> >> function should have:
> >>
> >> auto joiner(RoR, Separator)(RoR r, Separator sep);
> >>
> >> How would you guarantee upfront what kind of exceptions it can throw is beyond me. It all depends on code that you can't reach or know by the very definition of template.

The good thing is whatever your argument is, nothrow inevitably has to suffer from it, too.
Really I'd like to label this situation as 'bad', when you don't know what exceptions a function may throw. Then why have different exception types at all?

> > Well, presumably the exception specification would be inferred automatically for templates.
> 
> What's the propose then? And how end user will get any idea what to put in his function where he uses it? I see one, but it's not pretty - run compiler once - see complaints, add requested types to throws, re-run the compiler?

Yes it is that bad(tm) ^^. Ok, who is the end user? If I am the user of someone's library and it has an @throws(...) spec, I get an exact idea what to put into my code to handle the exceptions - if I want to.

If I'm writing library code on the other hand it depends on the business I'm doing. I'd expect that fast living close to the market code will likely not use this feature, whereas libraries want to be specific about their public API, which includes the exceptions that they throw. I see it as a final step alongside the documentation of a library to add the @throws(...), so it doesn't break the workflow much.

As for the benefits:

o can act as a contract in class hierarchies when used on overrideable methods
o allows you to decide at any point to limit the thrown exceptions to a certain set
  (e.g. handle cases of ConvException or UTFException before the public API)
o makes this automatically visible in DDoc (including any comment on the exception)
  @throws(ReadException /** if it is not correct. */);
o you don't have to document them manually and keep the DDoc up to date,
  which is much more time consuming than running the compiler twice
o let the compiler work for you
o I am a lousy salesman writing walls of text


Take a look for example at the socket API. Some methods specify the thrown exceptions, others only hint at them by catching them in examples or don't document them at all. You have to start guessing or digging through the source code to find out which error situations result in what exceptions. The InternetAddress ctor taking a host name looks innocent for example as well as most of the Socket methods.

In std.datetime, there is a function TimeZone.getInstalledTZNames() where I wonder if the docs are correct. They say on Windows it throws a DateTimeException when the registry cannot be read, but around the actual registry function call I see no try catch to wrap the thrown exception.

std.format is sometimes throwing FormatException, but sometimes Exception on similar cases or an UTFException.

-- 
Marco

August 13, 2012
Am Mon, 13 Aug 2012 20:17:12 +0200
schrieb "Nathan M. Swan" <nathanmswan@gmail.com>:

> On Monday, 13 August 2012 at 10:02:23 UTC, Marco Leise wrote:
> > Thoughts ?
> 
> I like this idea - you can use checked exceptions, but you aren't forced.
> 
> Though I think private and free functions should by default just use @throws(Exception). Not using @throws is like saying "I don't pay attention to what errors might occur, a new version might be different."
> 
> NMS

Ok, that would simplify the concept, but what would you do about templated functions that operate on ranges, like Dimitry presented? I'd rather have the compiler deduce the exceptions to @throws() where I passed in a simple int[], than have to deal with @throws(Exception). For normal functions it may be feasible.
Also all existing code is not annotated, leaving us in the same situation as with other missing attributes in Phobos and people start to complain "I'd like to use @throws, but everything is just @throws(Exception)" :p

-- 
Marco

August 14, 2012
On Monday, 13 August 2012 at 15:32:45 UTC, Dmitry Olshansky wrote:
> So (*yawn*) tell what kind of exception specification the following function should have:
>
> auto joiner(RoR, Separator)(RoR r, Separator sep);



auto joiner(RoR, Separator)(RoR r, Separator sep)
	throws(?);
August 14, 2012
On Tuesday, 14 August 2012 at 23:13:07 UTC, Mehrdad wrote:
> On Monday, 13 August 2012 at 15:32:45 UTC, Dmitry Olshansky wrote:
>> So (*yawn*) tell what kind of exception specification the following function should have:
>>
>> auto joiner(RoR, Separator)(RoR r, Separator sep);
>
>
>
> auto joiner(RoR, Separator)(RoR r, Separator sep)
> 	throws(?);


Or even better:

auto joiner(RoR, Separator)(RoR r, Separator sep)
	throws(auto);


That way it's easy enough for the programmer to make the compiler shut up (it's certainly easier than swallowing the exception), while allowing him to write functions that are perfectly transparent toward exceptions, and which would be allowed to throw/catch as they would in any other exception-unchecked language.


IMO it would work well in practice.