On 29/09/2014 10:06, Walter Bright wrote:
> On 9/29/2014 1:27 AM, Johannes Pfau wrote:
>> In a daemon which logs to syslog or in a GUI application or a game an
>> uncaught 'disk full exception' would go completely unnoticed and that's
>> definitely a bug.
>
> Failure to respond properly to an input/environmental error is a bug.
> But the input/environmental error is not a bug. If it was, then the
> program should assert on the error, not throw.
>

I agree. And isn't that exactly what Teoh said then:
"That's why I said, an uncaught exception is a BUG. "

I think people should be more careful with the term "uncaught exception" because it's not very precise.


-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros

On 28/09/2014 00:15, Walter Bright wrote:
> This issue comes up over and over, in various guises. I feel like
> Yosemite Sam here:
>
> https://www.youtube.com/watch?v=hBhlQgvHmQ0
>
> In that vein, Exceptions are for either being able to recover from
> input/environmental errors, or report them to the user of the application.
>
> When I say "They are NOT for debugging programs", I mean they are NOT
> for debugging programs.
>

This is incorrect.

Yes, the primary purpose of Exceptions is not for debugging, but to report exceptional state to the user (or some other component of the system).

But they also have a purpose for debugging, particularly the stack traces of exceptions. Take what you said:

"Failure to respond properly to an input/environmental error is a bug.
But the input/environmental error is not a bug. If it was, then the
program should assert on the error, not throw. "

So, some component/function Foo detects an environmental error, and throws and Exception, accordingly. Foo is not responsible for handling these errors, but some other component is.

Component/function Bar is the one that should handle such an error (for example, it should display a dialog to the user, and continue the application). But due to a bug, it doesn't do so, and the Exception goes all the way through main().

The programmer notices this happening, and clearly recognizes it's a bug (but doesn't know where the bug is, doesn't know that it's Bar that should be handling it). Now, what is best, to just have the Exception message (something like "File not found") displayed to the programmer - or even an end-user that could report a bug -, or to have the stack trace of the Exception so that the programmer can more easily look at which function should be handling it?

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros

On 29/09/2014 19:58, Steven Schveighoffer wrote:
> Any uncaught exceptions are BY DEFINITION programming errors.

Not necessarily.
For some applications (for example simple console apps), you can consider the D runtime's default exception handler to be an appropriate way to respond to the exception.

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros

On 10/1/14 9:47 AM, Bruno Medeiros wrote:
> On 29/09/2014 19:58, Steven Schveighoffer wrote:
>> Any uncaught exceptions are BY DEFINITION programming errors.
>
> Not necessarily.
> For some applications (for example simple console apps), you can
> consider the D runtime's default exception handler to be an appropriate
> way to respond to the exception.
>

No, this is lazy/incorrect coding. You don't want your user to see an indecipherable stack trace on purpose.

-Steve

On 29/09/2014 05:03, Sean Kelly wrote:
>> I recall Toyota got into trouble with their computer controlled cars
>> because of their idea of handling of inevitable bugs and errors. It
>> was one process that controlled everything. When something unexpected
>> went wrong, it kept right on operating, any unknown and unintended
>> consequences be damned.
>>
>> The way to get reliable systems is to design to accommodate errors,
>> not pretend they didn't happen, or hope that nothing else got
>> affected, etc. In critical software systems, that means shut down and
>> restart the offending system, or engage the backup.
>
> My point was that it's often more complicated than that.  There have
> been papers written on self-repairing systems, for example, and ways to
> design systems that are inherently durable when it comes to even
> internal errors.  I think what I'm trying to say is that simply aborting
> on error is too brittle in some cases, because it only deals with one
> vector--memory corruption that is unlikely to reoccur.  But I've watched
> always-on systems fall apart from some unexpected ongoing situation, and
> simply restarting doesn't actually help.

Sean, I fully agree with the points you have been making so far.
But if Walter is fixated on thinking that all the practical uses of D will be critical systems, or simple (ie, single-use, non-interactive) command-line applications, it will be hard for him to comprehend the whole point that "simply aborting on error is too brittle in some cases".

PS: Walter, what browser to you use?

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros

On 29/09/2014 20:28, Sean Kelly wrote:
> Checked exceptions are good in theory but they failed utterly in
> Java.  I'm not interested in seeing them in D.

That is the conventional theory, the established wisdom.
But the more I become experienced with Java, over the years, I've become convinced otherwise.

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.

Like Jeremy mentioned, if one puts catch blocks right around the function that throws an exception, and just swallow/forget it there without doing anything else, then it's totally the programmers fault for being lazy.

If one is annoyed that often, adding a throws clause in a function will require adding the same throws clause function to several other functions, well, that is editing work you have to accept for the sake of more correctness. But also one should understand there are ways to mitigate this editing work:

First point is that in a lot of code, is better to have a function throw just one generic (but checked) exception, that can wrap any other specific errors/exceptions. If you are doing an operation that can throw File-Not-Found, Invalid-Path, No-Permissions, IO-Exception, etc., then often all of these will be handled in the same user-reporting code, so they could be wrapped under a single exception that would be used in the throws clause. And so the whole function call chain doesn't need to be modified every time a new exception is added or removed.

If you're thinking that means adding a "throws Exception" to such functions in Java, then no. Because this will catch RuntimeExceptions too (the unchecked exceptions of Java), and these you often want to handle elsewhere than where you handle the checked exceptions. In this regard, Java does have a design fault, IMO, which is that there is no common superclass for checked Exceptions. (there is only for unchecked exceptions)

The second point, is that even adding (or modifying) the throws clause of function signatures cause be made much easier with an IDE, and in particular Eclipse JDT helps a lot. If you have an error in the editor about a checked exception that is not caught or thrown, you can just press Ctrl-1 to automatically add either a throws clause, or a surrounding try-catch block.

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros

Bruno Medeiros:

> But if Walter is fixated on thinking that all the practical uses of D will be critical systems, or simple (ie, single-use, non-interactive) command-line applications,

There's still some of way to go for D design to make it well fit for high integrity systems (some people even use a restricted subset of C for such purposes, but it's a bad language for it).

Bye,
bearophile

On 01/10/2014 14:55, Steven Schveighoffer wrote:
> On 10/1/14 9:47 AM, Bruno Medeiros wrote:
>> On 29/09/2014 19:58, Steven Schveighoffer wrote:
>>> Any uncaught exceptions are BY DEFINITION programming errors.
>>
>> Not necessarily.
>> For some applications (for example simple console apps), you can
>> consider the D runtime's default exception handler to be an appropriate
>> way to respond to the exception.
>>
>
> No, this is lazy/incorrect coding. You don't want your user to see an
> indecipherable stack trace on purpose.
>
> -Steve

Well, at the very least it's bad UI design for sure (textual UI is still UI).
But it's only a *bug* if it's not the behavior the programmer intended.


-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros

On 10/1/14 10:36 AM, Bruno Medeiros wrote:
> On 01/10/2014 14:55, Steven Schveighoffer wrote:
>> On 10/1/14 9:47 AM, Bruno Medeiros wrote:
>>> On 29/09/2014 19:58, Steven Schveighoffer wrote:
>>>> Any uncaught exceptions are BY DEFINITION programming errors.
>>>
>>> Not necessarily.
>>> For some applications (for example simple console apps), you can
>>> consider the D runtime's default exception handler to be an appropriate
>>> way to respond to the exception.
>>>
>>
>> No, this is lazy/incorrect coding. You don't want your user to see an
>> indecipherable stack trace on purpose.
>>
>> -Steve
>
> Well, at the very least it's bad UI design for sure (textual UI is still
> UI).
> But it's only a *bug* if it's not the behavior the programmer intended.

Sure, one could also halt a program by reading a null pointer on purpose. 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.

-Steve

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.