On Fri, Feb 24, 2012 at 04:38:31PM -0500, Steven Schveighoffer wrote: [...]
> On to my second point.  One of the issues I have with Java is that exceptions are *overused*.  For example, EOF should not be an exception, most files have ends, it's not a very exceptional situation.  If there is an intuitive way to use an existing return value to convey an error rather than an exception, I'd prefer the return value.  There is a runtime cost just for setting up a try/catch block, even if no exceptions are thrown.
[...]

Yeah, EOF shouldn't be an exception. It should simply be a terminal state that file-reading code gets into, whereupon it will simply return some special value (e.g., dchar.init, or empty array) upon further reading. Preferably also have a .eof or .empty method or something equivalent that indicates EOF, so you can write "while (!obj.eof) { ... }". Using an exception for EOF is abuse, IMO.

Another beef I have about EOFs is that I've seen code where EOF is returned only once, and then you're not supposed to call that code ever again after that because it will crash. I think that's really stupid. If you hit EOF, attempting to read further should simply return EOF again without changing the state of the system any further. Multiple attempts to read past EOF should still return EOF. (One would think this was obvious, but obviously it's not very obvious...)


T

-- 
To err is human; to forgive is not our policy. -- Samuel Adler

On Friday, February 24, 2012 16:18:59 H. S. Teoh wrote:
> On Fri, Feb 24, 2012 at 06:48:47PM -0500, Jonathan M Davis wrote:

> > 1. Being able to annotate catch blocks in some manner to enable them to catch multiple, specific exceptions - either by using some kind of condition
> > 
> > catch(Ex1 e) if(condition)
> 
> Even though I was (one of) the one(s) who proposed this syntax, I think
> a better syntax would be something like:
> 
> catch(Ex1 e: condition)
> 
> but that's just bikeshedding.
> 
> > which, as you point out, would have to be done at runtime, or by doing something similar to what Java 7 is doing and make it so that multiple exceptions can be caught with the same block
> > 
> > catch(Ex1, Ex2, Ex3 e)
> > 
> > and e ends up being the most derived type that is common to them.
> 
> This can also be done by catch conditions by using is-expressions or derived class casts, though it would be more verbose. We may not need to implement both.

You do run into the who rethrowing issue with that though, if you catch the wrong type. It also can force you to combine disparate catch blocks, since you caught the common type, and you're forced to use if-else statements to separate out the various cases instead of letting catch take care of it. All in all, it would just be _way_ cleaner to have a way to give a list of exception types that you want that catch to catch.

Also, I think that having a syntax for simply giving a list of exceptions that an exception block catches is plenty without needing the whole condition thing. The condition thing just seems like overkill. But maybe someone has a valid use case where giving a specific list of exceptions doesn't cut it.

> I don't think D's job is to stop people from doing stupid things. Otherwise we might as well go back to Pascal or something. :)

Indeed. What we need is a setup which enables (and hopefully encourages) people to do the right thing. We can't stop people from being stupid.

For instance, much as Java generally tries to protect you from your own stupidity, the fact that it has very good exception hierarchy doesn't stop people (and in some cases the developers of its standard library) from doing stupid things with exceptions. And D, which tries to protect you without preventing you from being stupid (unlike Java, which generally tries to prevent you from doing something stupid), certainly isn't going to stop you from being stupid.

- Jonathan M Davis

On 02/21/2012 07:57 PM, deadalnix wrote:
> opDispatch is nice, but rather incomplete. It doesn't handle template
> methods for example.

It surely does.

struct S{
    template opDispatch(string op){
        auto opDispatch(T...)(T args){
            writeln(op, args);
        }
    }
}
void main() {
    S s;
    s.foo(1,2.0,"bar");
}

On 02/24/2012 08:14 PM, Andrei Alexandrescu wrote:
> On 2/24/12 1:13 PM, H. S. Teoh wrote:
>> In my mind, contract code belongs in the function signature, because
>> they document how the function expects to be called, and what it
>> guarantees in return. It doesn't seem to make sense to me that contracts
>> would be hidden from the user of the library. Sorta defeats the purpose,
>> since how is the user supposed to know what the function expects? Rely
>> on documentation, perhaps, but docs aren't as reliable as actual
>> contract code.
>
> Yah, and that's why we managed, with great implementation effort, to
> allow contract checks in interfaces. The concept has still to take off
> though.
>
> Andrei

'In' contracts are hardly usable at all at the moment, because they are not inherited by default.

On 2/25/12 7:19 AM, Timon Gehr wrote:
> On 02/24/2012 08:14 PM, Andrei Alexandrescu wrote:
>> On 2/24/12 1:13 PM, H. S. Teoh wrote:
>>> In my mind, contract code belongs in the function signature, because
>>> they document how the function expects to be called, and what it
>>> guarantees in return. It doesn't seem to make sense to me that contracts
>>> would be hidden from the user of the library. Sorta defeats the purpose,
>>> since how is the user supposed to know what the function expects? Rely
>>> on documentation, perhaps, but docs aren't as reliable as actual
>>> contract code.
>>
>> Yah, and that's why we managed, with great implementation effort, to
>> allow contract checks in interfaces. The concept has still to take off
>> though.
>>
>> Andrei
>
> 'In' contracts are hardly usable at all at the moment, because they are
> not inherited by default.

I thought that was fixed. Is there a bug report on it? Thanks!

Andrei

On 02/25/2012 09:18 PM, Andrei Alexandrescu wrote:
> On 2/25/12 7:19 AM, Timon Gehr wrote:
>> On 02/24/2012 08:14 PM, Andrei Alexandrescu wrote:
>>> On 2/24/12 1:13 PM, H. S. Teoh wrote:
>>>> In my mind, contract code belongs in the function signature, because
>>>> they document how the function expects to be called, and what it
>>>> guarantees in return. It doesn't seem to make sense to me that
>>>> contracts
>>>> would be hidden from the user of the library. Sorta defeats the
>>>> purpose,
>>>> since how is the user supposed to know what the function expects? Rely
>>>> on documentation, perhaps, but docs aren't as reliable as actual
>>>> contract code.
>>>
>>> Yah, and that's why we managed, with great implementation effort, to
>>> allow contract checks in interfaces. The concept has still to take off
>>> though.
>>>
>>> Andrei
>>
>> 'In' contracts are hardly usable at all at the moment, because they are
>> not inherited by default.
>
> I thought that was fixed. Is there a bug report on it? Thanks!
>
> Andrei

This is the bug report:
http://d.puremagic.com/issues/show_bug.cgi?id=6856

( Furthermore, there is an issue with the design:
http://d.puremagic.com/issues/show_bug.cgi?id=7584 )

Le 25/02/2012 14:10, Timon Gehr a écrit :
> On 02/21/2012 07:57 PM, deadalnix wrote:
>> opDispatch is nice, but rather incomplete. It doesn't handle template
>> methods for example.
>
> It surely does.
>
> struct S{
> template opDispatch(string op){
> auto opDispatch(T...)(T args){
> writeln(op, args);
> }
> }
> }
> void main() {
> S s;
> s.foo(1,2.0,"bar");
> }

Explicit template argument, I should have precised.

On 02/26/2012 01:12 PM, deadalnix wrote:
> Le 25/02/2012 14:10, Timon Gehr a écrit :
>> On 02/21/2012 07:57 PM, deadalnix wrote:
>>> opDispatch is nice, but rather incomplete. It doesn't handle template
>>> methods for example.
>>
>> It surely does.
>>
>> struct S{
>> template opDispatch(string op){
>> auto opDispatch(T...)(T args){
>> writeln(op, args);
>> }
>> }
>> }
>> void main() {
>> S s;
>> s.foo(1,2.0,"bar");
>> }
>
> Explicit template argument, I should have precised.

Please validate your non-trivial claims before you make them. Otherwise, time gets wasted discussing non-existent problems. A good way to ensure what you claim is true is to always provide a minimal code example that demonstrates the claim, after having verified that the code indeed exposes the problematic behavior when compiled with the latest version of the reference compiler.

On Saturday, 18 February 2012 at 22:35:58 UTC, Jonathan M Davis
wrote:
> I'd hate to see us have a crippled exception hierarchy just because some
> people mishandle exceptions and simply print out messages on failure in all
> cases. Obviously sometimes that's what you have to do, but often you can
> handle them much better, and that's part of the reason that we  have
> _Exception_ and not just Error. And a proper exception hierarchy can be very
> benificial to programmers who actually use it correctly.

+1

Inheritance in general can (and is) misused too. Does that mean
that should also be banned?

Regards,

Ben

On 24/02/12 13:47, Regan Heath wrote:
> On Thu, 23 Feb 2012 15:13:17 -0000, James Miller <james@aatch.net> wrote:
>> On 23 February 2012 05:09, Regan Heath <regan@netmail.co.nz> wrote:
>>> On Tue, 21 Feb 2012 14:19:17 -0000, Andrei Alexandrescu
>>> <SeeWebsiteForEmail@erdani.org> wrote:
>>>
>>>> On 2/21/12 5:55 AM, Regan Heath wrote:
>>>>>
>>>>> On Sun, 19 Feb 2012 23:04:59 -0000, Andrei Alexandrescu
>>>>> <SeeWebsiteForEmail@erdani.org> wrote:
>>>>>
>>>>>> On 2/19/12 4:00 PM, Nick Sabalausky wrote:
>>>>>
>>>>>
>>>>>>> Seriously, how is this not *already* crystal-clear? I feel as if
>>>>>>> every few
>>>>>>> weeks you're just coming up with deliberately random shit to
>>>>>>> argue so
>>>>>>> the
>>>>>>> rest of us have to waste our time spelling out the obvious in
>>>>>>> insanely
>>>>>>> pedantic detail.
>>>>>>
>>>>>>
>>>>>> It sometimes happened to me to be reach the hypothesis that my
>>>>>> interlocutor must be some idiot. Most often I was missing something.
>>>>>
>>>>>
>>>>> I get the impression that you find "Devil's advocate" a useful tool
>>>>> for
>>>>> generating debate and out of the box thinking.. there is something
>>>>> to be
>>>>> said for that, but it's probably less annoying to some if you're clear
>>>>> about that from the beginning. :p
>>>>
>>>>
>>>> Where did it seem I was playing devil's advocate? Thanks.
>>>
>>>
>>> "Devil's Advocate" is perhaps not the right term, as you don't seem
>>> to ever
>>> argue the opposite to what you believe. But, it occasionally seems to me
>>> that you imply ignorance on your part, in order to draw more information
>>> from other posters on exactly what they think or are proposing. So, some
>>> get frustrated as they feel they have to explain "everything" to you
>>> (and
>>> not just you, there have been times where - for whatever reason - it
>>> seems
>>> that anything less than a description of every single minute detail
>>> results
>>> in a miss understanding - no doubt partly due to the medium in which
>>> we are
>>> communicating).
>>>
>>>
>>> Regan
>>>
>>> --
>>> Using Opera's revolutionary email client: http://www.opera.com/mail/
>>
>> I think that is technically called being facetious.
>
> Doesn't seem quite right to me:
> http://dictionary.reference.com/browse/facetious
>
> R

Socratic irony?