On 10/1/14 11:00 AM, Andrej Mitrovic via Digitalmars-d wrote:
> On 10/1/14, Steven Schveighoffer via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> No, this is lazy/incorrect coding. You don't want your user to see an
>> indecipherable stack trace on purpose.
>
> So when they file a bug report are you going to also ask them to run
> the debugger so they capture the stack trace and file that to you?
> Come on.
>

No what I mean is:

./niftyapp badfilename.txt

Result should be:

Error: Could not open badfilename.txt, please check and make sure the file exists and is readable.

Not:

std.exception.ErrnoException@std/stdio.d(345): Cannot open file `badfilename.txt' in mode `rb' (No such file or directory)
----------------
5   testexception                       0x0000000104fad02d ref std.stdio.File std.stdio.File.__ctor(immutable(char)[], const(char[])) + 97
6   testexception                       0x0000000104f8d735 _Dmain + 69
7   testexception                       0x0000000104f9f771 void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll().void __lambda1() + 33
8   testexception                       0x0000000104f9f6bd void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate()) + 45
9   testexception                       0x0000000104f9f71d void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll() + 45
10  testexception                       0x0000000104f9f6bd void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate()) + 45
11  testexception                       0x0000000104f9f639 _d_run_main + 449
12  testexception                       0x0000000104f8d75c main + 20
13  libdyld.dylib                       0x00007fff8fb2a5fd start + 1
14  ???                                 0x0000000000000001 0x0 + 1

If it's an error due to *user input*, you should not rely on the exception handling of the runtime, you should have a more user-friendly message.

Obviously, if you fail to handle it, the full trace happens, and then you must fix that in your code.

It's for your benefit too :) This way you get less nuisance troubleshooting calls since the error message is clearer.

-Steve

On Wednesday, 1 October 2014 at 14:46:50 UTC, Steven Schveighoffer wrote:
> On 10/1/14 10:36 AM, Bruno Medeiros wrote:
>
>This is a grey area that I think reasonable people
> can correctly call a bug if they so wish, despite the intentions of the developer.

Correctly?

In a discussion, It's amazing how difficult it is to agree also on simple words meaning: an _intentional programmer behaviour_ a bug?

Whah ;-P

---
/Paolo

On 2014-09-29 17:13, Steven Schveighoffer wrote:

> Is it? I can think of cases where it's programmer error, and cases where
> it's user error.

When would it be a user error?

-- 
/Jacob Carlborg

On 10/1/14 3:24 PM, Paolo Invernizzi wrote:
> On Wednesday, 1 October 2014 at 14:46:50 UTC, Steven Schveighoffer wrote:
>> On 10/1/14 10:36 AM, Bruno Medeiros wrote:
>>
>> This is a grey area that I think reasonable people
>> can correctly call a bug if they so wish, despite the intentions of
>> the developer.
>
> Correctly?
>
> In a discussion, It's amazing how difficult it is to agree also on
> simple words meaning: an _intentional programmer behaviour_ a bug?

More appropriately, it's not a bug but an incorrect design. I still would call it a bug, and I'm 99% sure the users would report it as a bug :)

-Steve

On 10/1/14 3:27 PM, Jacob Carlborg wrote:
> On 2014-09-29 17:13, Steven Schveighoffer wrote:
>
>> Is it? I can think of cases where it's programmer error, and cases where
>> it's user error.
>
> When would it be a user error?
>

./progThatExpectsFilename ""

-Steve

On Wed, Oct 1, 2014 at 7:24 AM, Bruno Medeiros via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

>
> What has failed is not the concept of checked exceptions per se, but mostly, the failure of Java programmers to use checked exceptions effectively, and properly design their code around this paradigm.
>
>
This.

I have seen many java programs (and their programmers) fail utterly at using exceptions.  Like OO, the design of the system has to leverage it properly, and there are places where people can easily get tripped up - but when used well, can be immensely useful.

Error handling is part of an API, and exceptions are error handling, so should be considered when designing API.  Checked exceptions are a language-supported way to do this.

For those that consider checked exceptions a failure: what other feature(s)
would work instead?


NB:
If you see "throws Exception" in java code chances are the code is broken,
same as if you see "catch (Exception" - this tells you nothing about the
exception that happened, and hence you can do nothing with it.  So you
either swallow (and silently break in many cases) or rethrow (and break for
things you needn't have).  As mentioned, the standard way to avoid this is
to have a parent exception type appropriate to the abstraction in the API,
and throw subtypes in the implementation.  Among other things, this means
you can change the implementation to throw different exceptions without
breaking any users (who will already be catching the parent exception).
Adding/modifying a throws clause is an API-breaking change, so should be
avoided however easy it is in the IDE.
(Yes, I'm biased to writing libraries consumed by others)

NNB: Retrofitting a program to use proper exception handling is much harder than it is to design it the right way from scratch.  I'm going to compare to OO again: don't consider OO broken because people use inheritance when they want ownership, and it is painful to fix later.

On Wednesday, 1 October 2014 at 22:42:27 UTC, Jeremy Powers via
Digitalmars-d wrote:
>
> If you see "throws Exception" in java code chances are the code is broken,
> same as if you see "catch (Exception" - this tells you nothing about the
> exception that happened, and hence you can do nothing with it.  So you
> either swallow (and silently break in many cases) or rethrow (and break for things you needn't have).  As mentioned, the standard way to avoid this is to have a parent exception type appropriate to the abstraction in the API, and throw subtypes in the implementation.  Among other things, this means you can change the implementation to throw different exceptions without breaking any users (who will already be catching the parent exception).

...while in Phobos, most of the subtyped exceptions were
eliminated a while back in favor of just always throwing
Exception.

On Wednesday, 1 October 2014 at 23:00:41 UTC, Sean Kelly wrote:
> ...while in Phobos, most of the subtyped exceptions were
> eliminated a while back in favor of just always throwing
> Exception.

What are you referring to specifically? Compared to Tango, yes, Phobos might have a lot fewer concrete exception types. But I don't recall actually eliminating existing ones.

David

On 10/1/14, 4:00 PM, Sean Kelly wrote:
> On Wednesday, 1 October 2014 at 22:42:27 UTC, Jeremy Powers via
> Digitalmars-d wrote:
>>
>> If you see "throws Exception" in java code chances are the code is
>> broken,
>> same as if you see "catch (Exception" - this tells you nothing about the
>> exception that happened, and hence you can do nothing with it. So you
>> either swallow (and silently break in many cases) or rethrow (and
>> break for things you needn't have).  As mentioned, the standard way to
>> avoid this is to have a parent exception type appropriate to the
>> abstraction in the API, and throw subtypes in the implementation.
>> Among other things, this means you can change the implementation to
>> throw different exceptions without breaking any users (who will
>> already be catching the parent exception).
>
> ....while in Phobos, most of the subtyped exceptions were
> eliminated a while back in favor of just always throwing
> Exception.

My recollection is that was only talked about. Anyhow, one thing is clear - as of now there are no clear idioms and successful techniques for handling errors with exceptions (including the use of subtyping). -- Andrei

On 02/10/14 01:19, Andrei Alexandrescu wrote:

> My recollection is that was only talked about. Anyhow, one thing is
> clear - as of now there are no clear idioms and successful techniques
> for handling errors with exceptions (including the use of subtyping). --
> Andrei

I think most error handling is done with "enforce", this will, by default, throw an instance of Exception. I really, really hate this. I think Exception should be an abstract class or an interface.

-- 
/Jacob Carlborg