August 12, 2012
Perhaps a workable compromise is to make ddoc able to automatically output the throws list.

That way, we don't have the hassle of checks, but we do have a maintained list at relatively no hassle.


If you call a function to which the source code isn't available, ddoc can just point you toward that function's docs. It won't be 100% complete due to this, but I think it would be decent.
August 12, 2012
On Sun, 12 Aug 2012 16:33:39 +0200, Adam D. Ruppe <destructionator@gmail.com> wrote:

> Perhaps a workable compromise is to make ddoc able to automatically output the throws list.
>
> That way, we don't have the hassle of checks, but we do have a maintained list at relatively no hassle.
>
>
> If you call a function to which the source code isn't available, ddoc can just point you toward that function's docs. It won't be 100% complete due to this, but I think it would be decent.

Once we get a lexer, parser and lint tool, undocumented parameters, exceptions etc could be marked as warnings too.
Looking into the future here of course :)
August 12, 2012
On Sunday, August 12, 2012 16:33:39 Adam D. Ruppe wrote:
> Perhaps a workable compromise is to make ddoc able to automatically output the throws list.
> 
> That way, we don't have the hassle of checks, but we do have a maintained list at relatively no hassle.

That's both a good idea and bad idea, because all it's going to be able to list is the exceptions thrown directly in the function. In order to list them all, it would have to go digging through the whole call list (which not only would be expensive, but isn't even necessarily possible if the source isn't fully available), and if any classes are involved, then inheritence could totally mess up the list, since different derived classes could throw different exceptions.

So, unless all you care about is what's thrown directly from the function, you'd end up with a very incomplete list. The advantage is that you'd at least have a partial list, but if it gave the impression that it was the whole list, then that would be a problem. Of course, writing it by hand also tends to only list what gets thrown directly (or maybe also what's thrown in the direct helpe functions), so there wouldn't necessarily be much difference. So, it may be close to what would be written by hand. It's definitely true though that it won't be listing all of the thrown exceptions in the general case.

- Jonathan M Davis
August 12, 2012
On 8/12/2012 4:48 AM, bearophile wrote:
> Paulo Pinto:
>
>> And when they have them, there are many other issues to take care of.<
>
> This is a bad argument because there are always other issues to take care of.
> Even if a firm buys an artificial intelligence able to self-write all the code,
> I am sure people in that firm will keep saying "we have many other issues beside
> writing code!".

Not at all. If you fail to focus on your priorities, you will fail.


August 13, 2012
Am Sun, 12 Aug 2012 14:34:58 +0200
schrieb "Paulo Pinto" <pjmlp@progtools.org>:

> On Sunday, 12 August 2012 at 11:48:23 UTC, bearophile wrote:
> > Paulo Pinto:
> >
> >>And when they have them, there are many other issues to take care of.<
> >
> > This is a bad argument because there are always other issues to take care of. Even if a firm buys an artificial intelligence able to self-write all the code, I am sure people in that firm will keep saying "we have many other issues beside writing code!".
> >
> > Bye,
> > bearophile
> 
> Sure it is, but I've learned that if you live in the Fortune 500 corporation world, it not worth fighting against it.
> 
> Actually there are a few talks in InfoQ about this type of issue.
> 
> http://www.infoq.com/presentations/Stop-Refactoring http://www.infoq.com/presentations/Who-Ever-Said-Programs-Were-Supposed-to-be-Pretty
> 
> --
> Paulo

There is code to be written in different areas of business for sure. There is rapid changing business code as yours, there is moderately changing application software, there are extensible tools like Eclipse and it goes further on to libraries and software used in sensitive areas, nuclear power plants, medical or mars robots.
So there's definitely people who don't want to be slowed down by unnecessary errors and strictness in the language because it doesn't make money, and others who want to have a look at every little warning to make the code as failsafe as possible. I'm thinking of unhandled exceptions as well as integer overflow and similar.
In the end your products wouldn't be finished in time either, if the libraries and tools you build them with weren't good. And open-source software often has the benefit there, that you can actually look at the source if something remains unclear in the documentation, and also that often a lot of people have looked over the code; people with different backgrounds and experience, that detect other types of bugs and pitfalls.
In that way success is not always defined economically. It is defined by the goals you set for a given project. A person who uses test driven development might chose D, because of its built in unit tests and invariant() {...}. Similarly a physicist might shy away from it, because of the semantic noise. (They want an integer, but are confronted with the concept of signed/unsigned 32 and 64 bit values and BitInts)

TL:DR - it all depends on your target audience :)

-- 
Marco

August 13, 2012
On Sunday, 12 August 2012 at 03:02:50 UTC, Marco Leise wrote:
> I just got a bit frustrated and wanted to say that I like working with Exceptions in Java a lot more.

I don't. When writing a simple command line program, when there's an error, it usually means the user messed up and I can't recover. I just print the message and terminate. I don't want to have to write "throws Exception" for everything.

void main(string[] args) {
    try {
        realMain(args);
        return 0;
    } catch (Exception e) {
        stderr.writeln(e.msg);
    }
}

The idea sounds nice, but it's annoying in practice. The point of exceptions is to _centralize_ error handling. Being forced to either catch or declare is almost as bad as C-style errno error handling.

Perhaps an annotation might be nice, as long as it doesn't force catching:

void buggyFunction(string file, int exception) @throws(StdioException);
August 13, 2012
Am Mon, 13 Aug 2012 10:00:31 +0200
schrieb "Nathan M. Swan" <nathanmswan@gmail.com>:

> On Sunday, 12 August 2012 at 03:02:50 UTC, Marco Leise wrote:
> > I just got a bit frustrated and wanted to say that I like working with Exceptions in Java a lot more.
> 
> I don't. When writing a simple command line program, when there's an error, it usually means the user messed up and I can't recover. I just print the message and terminate. I don't want to have to write "throws Exception" for everything.

But now and then you probably write something else than a simple command line program, right?

> The idea sounds nice, but it's annoying in practice. The point of exceptions is to _centralize_ error handling. Being forced to either catch or declare is almost as bad as C-style errno error handling.

Ok, it is annoying. Still exceptions are not just an opaque blob with a stack trace that you catch in your main(). They are more flexible, but it is difficult to efficiently use this flexibility. For example a routine that processes multiple files may continue with the next file on FileNotFoundExceptions, but throw others. A network application may attempt a few times to reconnect in case of a disconnect. That cannot be accomplished by one centralized exception handler. There are also a couple of occasions where a ConvException is better catched and rethrown as a BadServerResponseException (e.g. a number was expected, but something else returned).
In particular when writing a library I want to offer proper exceptions, and since they have the bad nature of aborting all your nested function calls, it is important for me to have the thrown exceptions properly declared - a task that the compiler can do better and faster than me.
As it stands I might diverge from my old practice and use only one exception type for a library.

> Perhaps an annotation might be nice, as long as it doesn't force catching:
> 
> void buggyFunction(string file, int exception) @throws(StdioException);

As someone else said, a D lint tool might help with warnings about undocumented thrown exceptions. But personally I want to be "annoyed" to death by the language until I have made it clear what I want to do with the exceptions, even if I just write "catch (ConvException) { /* cannot happen, input is known good */ }".

I don't know how many there are who think like me. Your @throws proposal for example could be used to tell the compiler that I want Java style checked exceptions for this function and have the compiler check that I listed them all. An empty list would actually be 'nothrow' then.

-- 
Marco

August 13, 2012
Am Mon, 13 Aug 2012 10:50:47 +0200
schrieb Marco Leise <Marco.Leise@gmx.de>:

> I don't know how many there are who think like me. Your @throws proposal for example could be used to tell the compiler that I want Java style checked exceptions for this function and have the compiler check that I listed them all. An empty list would actually be 'nothrow' then.

It's actually funny if you consider following 2 sentences from http://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html :

"Any Exception that can be thrown by a method is part of the method's public programming interface. Those who call a method must know about the exceptions that a method can throw so that they can decide what to do about them."

So it is the _public_ programming interface, we should be worried about, not forcing "throws"-lists onto every function and method that isn't intended to be called by others, which would neatly work with an optional @throws.

-- 
Marco

August 13, 2012
I think I should clarify some things up front.

o First of all, to be able to add @throws to a function at any point,
  means that the compiler would internally replace the flag 'isnothrow'
  with a list of thrown exceptions. That is not much different from what
  there is now and would be part of the mangled name as well, if
  acceptable (length restraints), or - since you cannot overload by
  exceptions - part of an extension to the object file.

o nothrow would be equivalent to the empty list @throws() and usable
  interchangeably.

o For protected and public methods of objects and interfaces that are
  not declared as nothrow, the thrown exceptions would inferred as
  @throws(Exception). This has to be done, since an override of these
  methods could introduce any exception type.

o private methods and regular functions are properly inferred with the
  exceptions they actually throw.

o At this point all the functions and methods carry their hidden @throws
  specification around, but it is neither visible in source code, nor is
  there any impact for developers.

o Once someone adds an @throws to a function, the compiler compares it to
  its internal list and complains if it is missing an exception type.
  The explicit list can contain additional exceptions that aren't in the
  compiler inferred list and it can offer more general exceptions, like
  the base type Exception, as a catch-all.

o What happens with object methods that don't declare anything?
  Since they are inferred as @throws(Exception), no narrowing is possible.
  On the other hand, I think this is the only natural way to handle it.

Thoughts ?

-- 
Marco

August 13, 2012
On Sun, 12 Aug 2012 22:01:49 +0100, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Sunday, August 12, 2012 16:33:39 Adam D. Ruppe wrote:
>> Perhaps a workable compromise is to make ddoc able to
>> automatically output the throws list.
>>
>> That way, we don't have the hassle of checks, but we do have a
>> maintained list at relatively no hassle.
>
> That's both a good idea and bad idea, because all it's going to be able to
> list is the exceptions thrown directly in the function. In order to list them
> all, it would have to go digging through the whole call list (which not only
> would be expensive, but isn't even necessarily possible if the source isn't
> fully available), and if any classes are involved, then inheritence could
> totally mess up the list, since different derived classes could throw different
> exceptions.
>
> So, unless all you care about is what's thrown directly from the function,
> you'd end up with a very incomplete list. The advantage is that you'd at least
> have a partial list, but if it gave the impression that it was the whole list,
> then that would be a problem. Of course, writing it by hand also tends to only
> list what gets thrown directly (or maybe also what's thrown in the direct
> helpe functions), so there wouldn't necessarily be much difference. So, it may
> be close to what would be written by hand. It's definitely true though that it
> won't be listing all of the thrown exceptions in the general case.

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.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/