On Monday, 29 September 2014 at 07:52:33 UTC, Paolo Invernizzi
wrote:
> On Monday, 29 September 2014 at 04:03:37 UTC, Sean Kelly wrote:
>> On Monday, 29 September 2014 at 02:57:03 UTC, Walter Bright
>>
>> Right.  But if the condition that caused the restart persists, the process can end up in a cascading restart scenario.  Simply restarting on error isn't necessarily enough.
>
> This can be mitigated: a cascade reboot would occur if the problem affects the reboot sequence itself.

Or if an ongoing situation causes the problem to rapidly reoccur.
  Look at most MMO game launches for example.  Production load
hits and some process falls over in a weird way, which increases
load because everyone goes nuts trying to log back in, and when
the system comes back up it immediately falls over again.  Rinse,
repeat.

On Monday, 29 September 2014 at 18:59:59 UTC, Jeremy Powers via
Digitalmars-d wrote:
>
> And this is an argument for checked exceptions - being able to explicitly state 'these are known fatal cases for this component, you should deal with them appropriately' when defining a method.  Cuts down the catch/check to just the common cases, and makes such cases explicit to the caller. Anything not a checked exception falls into the 'error, abort!' path.  (Memory corruption etc. being abort scenarios)

Checked exceptions are good in theory but they failed utterly in
Java.  I'm not interested in seeing them in D.

On Mon, Sep 29, 2014 at 11:58 AM, Steven Schveighoffer via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On 9/29/14 2:43 PM, Jeremy Powers via Digitalmars-d wrote:
>
>> On Mon, Sep 29, 2014 at 8:13 AM, Steven Schveighoffer via Digitalmars-d <digitalmars-d@puremagic.com <mailto:digitalmars-d@puremagic.com>> wrote:
>>
>>     My entire point is, it doesn't matter what is expected or what is
>>     treated as "correct." what matters is where the input CAME from. To
>>     a library function, it has no idea. There is no extra type info
>>     saying "this parameter comes from user input."
>>
>>
>>  From the method's view, parameters passed in are user input.  Full stop.
>>
>
> This is missing the point of an exception. An uncaught exception is an error which crashes the program. If you catch the exception, you can handle it, but if you don't expect it, then it's a bug. Any uncaught exceptions are BY DEFINITION programming errors.


I agree (except the bit about missing the point).  The point I wanted to make was that encapsulation means what is a fatal error to one part of a program may be easily handled by the containing part.  Just because an exception is thrown somewhere does not mean the program is broken - it is the failure to handle the exception (explicit or inadvertent) that indicates an error.


What is being discussed here is removing the stack trace and printout when
> an exception is thrown.
> ....


Sure, but it doesn't happen. Just like people do not check return values
> from syscalls.
>
> The benefit of the exception printing is at least you get a trace of where things went wrong when you didn't expect them to. Ignoring a call's return value doesn't give any notion something is wrong until much later.
>
> -Steve
>

I absolutely do not want a removal of stack trace information.  If an uncaught exception bubbles up and terminates the program, this is a bug and I sure as hell want to know as much about it as possible.  If having such information presented to the end user is unacceptable, then wrap and spew something better.

Ignoring an error return value is like ignoring an exception - bad news, and indicative of a broken program.

On Mon, Sep 29, 2014 at 12:28 PM, Sean Kelly via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> Checked exceptions are good in theory but they failed utterly in Java.  I'm not interested in seeing them in D.
>

I've heard this before, but have not seen a reasonable argument as to why they are a failure.  Last time this was discussed a link to a blog was provided, with lots of discussion there - which as far as I could tell boiled down to 'catching exceptions is ugly, and people just do the wrong thing anyway which is ugly when you have checked exceptions.'

I am unlucky enough to write Java all day, and from my standpoint checked exceptions are a huge win.  There are certain edges which can catch you, but they are immensely useful in developing robust programs.  Basically checked exceptions -> recoverable problems, unchecked -> unrecoverable/programming errors (like asserts or memory errors).

Note I am not advocating adding checked exceptions to D (though I would like it).  Point is to acknowledge that there are different kinds of exceptions, and an exception for one part of the code may not be a problem for the bit that invokes it.

On Monday, 29 September 2014 at 19:23:28 UTC, Sean Kelly wrote:
> On Monday, 29 September 2014 at 07:52:33 UTC, Paolo Invernizzi
> wrote:
>> On Monday, 29 September 2014 at 04:03:37 UTC, Sean Kelly wrote:
>>> On Monday, 29 September 2014 at 02:57:03 UTC, Walter Bright
>>>
>>> Right.  But if the condition that caused the restart persists, the process can end up in a cascading restart scenario.  Simply restarting on error isn't necessarily enough.
>>
>> This can be mitigated: a cascade reboot would occur if the problem affects the reboot sequence itself.
>
> Or if an ongoing situation causes the problem to rapidly reoccur.
>   Look at most MMO game launches for example.  Production load
> hits and some process falls over in a weird way, which increases
> load because everyone goes nuts trying to log back in, and when
> the system comes back up it immediately falls over again.  Rinse,
> repeat.

Is it not better to throttle down the connection volumes before it reach processes not being able to handle an overload in in a correct way?
---
/Paolo

On Monday, 29 September 2014 at 21:49:44 UTC, Paolo Invernizzi
wrote:
>
> Is it not better to throttle down the connection volumes before it reach processes not being able to handle an overload in in a correct way?

Well, it many cases it isn't the pure load numbers that are the
problem but the interaction of the behavior of actual real users.
  Like it isn't overly difficult to simulate a large volume of
traffic on a system, but it's extremely difficult to simulate
realistic behavior patters.  I think in many cases the problem
ends up being unexpected interactions of different behaviors that
cause problems rather than simply high volume.

On 9/29/14 3:44 PM, Jeremy Powers via Digitalmars-d wrote:
> On Mon, Sep 29, 2014 at 12:28 PM, Sean Kelly via Digitalmars-d
> <digitalmars-d@puremagic.com <mailto:digitalmars-d@puremagic.com>> wrote:
>
>     Checked exceptions are good in theory but they failed utterly in
>     Java.  I'm not interested in seeing them in D.
>
>
> I've heard this before, but have not seen a reasonable argument as to
> why they are a failure.  Last time this was discussed a link to a blog
> was provided, with lots of discussion there - which as far as I could
> tell boiled down to 'catching exceptions is ugly, and people just do the
> wrong thing anyway which is ugly when you have checked exceptions.'
>
> I am unlucky enough to write Java all day, and from my standpoint
> checked exceptions are a huge win.  There are certain edges which can
> catch you, but they are immensely useful in developing robust programs.
> Basically checked exceptions -> recoverable problems, unchecked ->
> unrecoverable/programming errors (like asserts or memory errors).

Well, the failure comes from the effort to effect a certain behavior.

Sun was looking to make programmers more diligent about handling errors. However, humans are lazy worthless creatures. What ends up happening is, the compiler complains they aren't handling an exception. They can't see any reason why the exception would occur, so they simply catch and ignore it to shut the compiler up.

In 90% of cases, they are right -- the exception will not occur. But because they have been "trained" to simply discard exceptions, it ends up defeating the purpose for the 10% of the time that they are wrong.

If you have been able to resist that temptation and handle every exception, then I think you are in the minority. But I have no evidence to back this up, it's just a belief.

> Note I am not advocating adding checked exceptions to D (though I would
> like it).  Point is to acknowledge that there are different kinds of
> exceptions, and an exception for one part of the code may not be a
> problem for the bit that invokes it.
>

I think this is appropriate for a lint tool for those out there like yourself who want that information. But requiring checked exceptions is I think a futile attempt to outlaw natural human behavior.

-Steve

On Tue, Sep 30, 2014 at 5:43 AM, Steven Schveighoffer via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> ...
> Well, the failure comes from the effort to effect a certain behavior.
>
> Sun was looking to make programmers more diligent about handling errors. However, humans are lazy worthless creatures. What ends up happening is, the compiler complains they aren't handling an exception. They can't see any reason why the exception would occur, so they simply catch and ignore it to shut the compiler up.
>
> In 90% of cases, they are right -- the exception will not occur. But because they have been "trained" to simply discard exceptions, it ends up defeating the purpose for the 10% of the time that they are wrong.
>
>
That's the argument, but it doesn't seem valid to me.  Without checked exceptions, you will always be ignoring exceptions.  With checked exceptions, you have to explicitly ignore (some) exceptions, and when you do it is immediately obvious in the code.  You go from everyone ignoring exceptions all the time, to some people ignoring them - and being able to easily notice and call out such.

Anyone 'trained' to ignore checked exceptions are simply shooting themselves in the foot - same as if there were no checked exceptions, but with more verbosity.  This is not a failure of checked exceptions, but a failure of people to use a language feature properly. (Which, yeah, meta is a failure of the feature... not going to go there)



> If you have been able to resist that temptation and handle every exception, then I think you are in the minority. But I have no evidence to back this up, it's just a belief.
>
>
In my world of professional java, ignoring exceptions is an immediate, obvious indicator of bad code.  You will be called on it, and chastised appropriately.  So from my standpoint, Sun was successful in making programmers more diligent about handling errors.



>  Note I am not advocating adding checked exceptions to D (though I would
>> like it).  Point is to acknowledge that there are different kinds of exceptions, and an exception for one part of the code may not be a problem for the bit that invokes it.
>>
>>
> I think this is appropriate for a lint tool for those out there like yourself who want that information. But requiring checked exceptions is I think a futile attempt to outlaw natural human behavior.
>
>
Perhaps I shouldn't have mentioned checked exceptions at all, seem to be distracting from what I wanted to say.  The important bit I wanted to bring to the discussion is that not all exceptions are the same, and different sections of code have their own ideas of what is a breaking problem.  A module/library/component/whatever treats any input into itself as its input, and thus appropriately throws exceptions on bad input.  But code using that whatever may be perfectly fine handling exceptions coming from there.

Exceptions need to be appropriate to the given abstraction, and dealt with by the user of that abstraction.

Am Sun, 28 Sep 2014 13:14:43 -0700
schrieb Walter Bright <newshound2@digitalmars.com>:

> On 9/28/2014 12:33 PM, Jacob Carlborg wrote:
> > On 2014-09-28 19:36, Walter Bright wrote:
> >
> >> I suggest removal of stack trace for exceptions, but leaving them in for asserts.
> >
> > If you don't like the stack track, just wrap the "main" function in a try-catch block, catch all exceptions and print the error message.
> 
> That's what the runtime that calls main() is supposed to do.

Guys, a druntime flag could settle matters in 10 minutes. But this topic is clearly about the right school of thought.

I use contracts to check for logical errors, like when an
argument must not be null or a value less than the length of
some data structure.
I use exceptions to check for invalid input and the return
values of external libraries. External libraries can be
anything from my own code in the same project to OpenGL from
vendor XY. They could error out on valid input (if we leave
out of memory aside for now), because of bugs or incorrect
assumptions of the implementation.
If that happens and all I get is:
"Library XY Exception: code 0x13533939 (Invalid argument)."
I'm at a loss, where the library might have had a hickup.
Did some function internally handle a uint as an int and
wrapped around?
Maybe with std.logger we will see single line messages on the
terminal and multi-line exception traces in the logs (which by
default print to stderr as well). And then this discussion can
be resolved.

-- 
Marco

On 28/09/2014 23:00, Walter Bright wrote:
> I can't get behind the notion of "reasonably certain". I certainly would
> not use such techniques in any code that needs to be robust,

On 29/09/2014 04:04, Walter Bright wrote:
> I know I'm hardcore and uncompromising on this issue, but that's where I
> came from (the aviation industry).

Walter, you do understand that not all software has to be robust - in the critical systems sense - to be quality software? And that in fact, the majority of software is not critical systems software?...

I was under the impression that D was meant to be a general purpose language, not a language just for critical systems. Yet, on language design issues, you keep making a series or arguments and points that apply *only* to critical systems software.


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