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.

---
/Paolo

Am Sun, 28 Sep 2014 17:47:56 -0700
schrieb Walter Bright <newshound2@digitalmars.com>:

> On 9/28/2014 4:18 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
> > I don't follow this point.  How can this approach work with programs that are built with the -release switch?
> 
> All -release does is not generate code for assert()s. To leave the asserts in, do not use -release. If you still want the asserts to be in even with -release,
> 
>      if (condition) assert(0);
> 

Right now, but some time ago there was a huge debate whether it should be valid for the compiler to optimize based on asserts.

I wonder if these 'use asserts for stack traces' and 'an assert is always supposed to pass, so it's valid to assume the condition holds (in release)' notions can go together. I guess it might at least lead to programs that are unusable when compiled with -release.

Am Sun, 28 Sep 2014 15:59:45 -0700
schrieb Walter Bright <newshound2@digitalmars.com>:

> > if the program failed to catch an exception, you're already screwed anyway
> 
> This is simply not true. One can write utilities with no caught exceptions at all, and yet have the program emit user friendly messages about "disk full" and stuff like that.

You're always thinking of simple console apps but this is the only place where the default 'print exception to console' strategy works.

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.

On Monday, 29 September 2014 at 08:18:29 UTC, Johannes Pfau wrote:
> Right now, but some time ago there was a huge debate whether it should
> be valid for the compiler to optimize based on asserts.
>
> I wonder if these 'use asserts for stack traces' and 'an assert is
> always supposed to pass, so it's valid to assume the condition holds
> (in release)' notions can go together. I guess it might at least lead
> to programs that are unusable when compiled with -release.

For this reason I think it makes more sense to use abort() if you plan to use "-release".

On Mon, 29 Sep 2014 10:18:27 +0200
Johannes Pfau via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> I wonder if these 'use asserts for stack traces' and 'an assert is always supposed to pass, so it's valid to assume the condition holds (in release)' notions can go together. I guess it might at least lead to programs that are unusable when compiled with -release.
compiler never optimizes away `assert(0)`, AFAIR. `assert(0)` is a
special thing, it means `abort()`.

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.

On 9/27/14 9:52 PM, Walter Bright wrote:
> On 9/27/2014 6:24 PM, Steven Schveighoffer wrote:
>> On 9/27/14 7:15 PM, Walter Bright wrote:
>>
>>> When I say "They are NOT for debugging programs", I mean they are NOT
>>> for debugging programs.
>>
>> Library code often cannot make that choice.
>> The issue with exceptions vs. errors
>> is that often you don't know where the input comes from.
>>
>> e.g.:
>>
>> auto f = File(someInternalStringThatIsCorrupted) -> error
>> auto f = File(argv[1]) -> exception
>>
>> How does File know what it's target file name came from?
>
> If the app is concerned about invalid filenames as bugs, you should
> scrub the filenames first. I.e. the interface is defined improperly if
> the code confuses a programming bug with input errors.

OK, so if you want to avoid improperly having errors/exceptions, don't put bugs into your code.

A simple plan!

-Steve

On 9/28/14 5:01 AM, Jacob Carlborg wrote:
> On 2014-09-28 03:24, Steven Schveighoffer wrote:
>
>> Library code often cannot make that choice. The issue with exceptions
>> vs. errors is that often you don't know where the input comes from.
>>
>> e.g.:
>>
>> auto f = File(someInternalStringThatIsCorrupted) -> error
>> auto f = File(argv[1]) -> exception
>>
>> How does File know what it's target file name came from?
>
> Both of theses should throw an exception. Most stuff related to file
> operations should throw an exception, not an error.
>

That makes no sense. The opening of the file is subject to issues with the filesystem, which means they may be environmental or user errors, not programming errors. But that doesn't mean the opening of the file failed because the file doesn't exist, it could be an error in how you construct the file name.

What about:

File f;
f.open(null);

Is that an environmental error or User error?

-Steve

On 9/29/2014 4:47 AM, Steven Schveighoffer wrote:
> On 9/27/14 9:52 PM, Walter Bright wrote:
>> On 9/27/2014 6:24 PM, Steven Schveighoffer wrote:
>>> On 9/27/14 7:15 PM, Walter Bright wrote:
>>>
>>>> When I say "They are NOT for debugging programs", I mean they are NOT
>>>> for debugging programs.
>>>
>>> Library code often cannot make that choice.
>>> The issue with exceptions vs. errors
>>> is that often you don't know where the input comes from.
>>>
>>> e.g.:
>>>
>>> auto f = File(someInternalStringThatIsCorrupted) -> error
>>> auto f = File(argv[1]) -> exception
>>>
>>> How does File know what it's target file name came from?
>>
>> If the app is concerned about invalid filenames as bugs, you should
>> scrub the filenames first. I.e. the interface is defined improperly if
>> the code confuses a programming bug with input errors.
>
> OK, so if you want to avoid improperly having errors/exceptions, don't put bugs
> into your code.
>
> A simple plan!

Validating user input is not the same thing as removing all the logic bugs from the program.

On 9/29/2014 4:51 AM, Steven Schveighoffer wrote:
> What about:
>
> File f;
> f.open(null);
>
> Is that an environmental error or User error?

Passing invalid arguments to a function is a programming bug.