On Wednesday, 1 February 2017 at 19:25:07 UTC, Ali Çehreli wrote:
tl;dr - Seeking thoughts on trusting a system that allows
"handling" errors.
One of my extra-curricular interests is the Mill CPU[1]. A
recent discussion in that context reminded me of the
Error-Exception distinction in
On Mon, 06 Feb 2017 18:12:38 +, Caspar Kielwein wrote:
> I absolutely agree with Walter and Ali, that there are applications
> where on Error anything but termination of the process is unacceptable.
Sure, and it looks like you spend a ton of effort to make things work
properly and to make
On 2/6/2017 9:10 AM, Chris Wright wrote:
Assuming that crashing results
in less loss of money or lives than marching on.
Any application that must continue or lives are lost is a BADLY designed system
and should not be tolerated.
On 02/06/2017 09:25 AM, Chris Wright wrote:
> https://github.com/munificent/vigil is the programming language for you.
Brilliant! :)
Ali
On Monday, 6 February 2017 at 17:40:50 UTC, Chris Wright wrote:
It works for every other programming language I've encountered.
This issue is language agnostic. It works in D as well but at
the same level of
correctness and unknowns.
I haven't heard anyone complaining about this elsewhere.
On Sun, 05 Feb 2017 22:23:19 -0800, Ali Çehreli wrote:
> On 02/05/2017 10:08 PM, Chris Wright wrote:
> > How do you recommend it leave behind enough data for me to
> > investigate the next day when I see there was a problem?
>
> The current approach is to rely on the backtrace produced when
On Mon, 06 Feb 2017 09:09:31 +, Dominikus Dittes Scherkl wrote:
> On Monday, 6 February 2017 at 06:08:22 UTC, Chris Wright wrote:
>> On Sat, 04 Feb 2017 23:48:48 -0800, Ali Çehreli wrote:
>>> What I and many others who say Errors should not be caught are saying
>>> is, once the program is in
On Sun, 05 Feb 2017 23:48:07 -0800, Walter Bright wrote:
> This discussion has come up repeatedly on this forum. Many people
> strongly disagree with me, and believe that they can recover from Errors
> and continue executing the program.
>
> That's fine if the program's output is nothing one
On 2017-02-06 08:48, Walter Bright wrote:
For example, if I feed a D source file to a C compiler and the C compiler
crashes, the C compiler has a bug in it, which is an Error. If the C
compiler instead writes a message "Error: D source code found instead of
C source code, please upgrade to a D
On Monday, 6 February 2017 at 06:08:22 UTC, Chris Wright wrote:
On Sat, 04 Feb 2017 23:48:48 -0800, Ali Çehreli wrote:
What I and many others who say Errors should not be caught are
saying is, once the program is in an unexpected state,
attempting to do anything further is wishful thinking.
On 2/1/2017 11:25 AM, Ali Çehreli wrote:
1) There is the well-known issue of whether Error should ever be caught. If
Error represents conditions where the application is not in a defined state,
hence it should stop operating as soon as possible, should that also carry over
to other applications,
On 02/05/2017 10:08 PM, Chris Wright wrote:
> On Sat, 04 Feb 2017 23:48:48 -0800, Ali Çehreli wrote:
>> What I and many others who say Errors should not be caught are saying
>> is, once the program is in an unexpected state, attempting to do
>> anything further is wishful thinking.
>
> I've been
On 02/05/2017 08:49 AM, Chris Wright wrote:
> On Sat, 04 Feb 2017 23:48:48 -0800, Ali Çehreli wrote:
>> Doesn't change what I'm saying. :) For example, RangeError may be thrown
>> due to a rogue function writing over memory that it did not intend to.
>> An index 42 may have become 42000 and that
On Sat, 04 Feb 2017 23:48:48 -0800, Ali Çehreli wrote:
> What I and many others who say Errors should not be caught are saying
> is, once the program is in an unexpected state, attempting to do
> anything further is wishful thinking.
I've been thinking about this a bit more, and I'm curious: how
On 02/05/2017 07:17 AM, Cym13 wrote:
On Saturday, 4 February 2017 at 07:24:12 UTC, Ali Çehreli wrote:
[...]
A bit OT but I'm pretty sure you would be very interested in GOTO;
2016's conference by Kevlin Henney titled "The Error of Our Ways" which
discusses the fact that most catastrophic
On Sat, 04 Feb 2017 23:48:48 -0800, Ali Çehreli wrote:
> Doesn't change what I'm saying. :) For example, RangeError may be thrown
> due to a rogue function writing over memory that it did not intend to.
> An index 42 may have become 42000 and that the RangeError may have been
> thrown. Fine. What
On Saturday, 4 February 2017 at 07:24:12 UTC, Ali Çehreli wrote:
[...]
A bit OT but I'm pretty sure you would be very interested in
GOTO; 2016's conference by Kevlin Henney titled "The Error of Our
Ways" which discusses the fact that most catastrophic
consequences of software come from very
On Wednesday, 1 February 2017 at 19:25:07 UTC, Ali Çehreli wrote:
tl;dr - Seeking thoughts on trusting a system that allows
"handling" errors.
One of my extra-curricular interests is the Mill CPU[1]. A
recent discussion in that context reminded me of the
Error-Exception distinction in
On 02/04/2017 08:17 AM, Chris Wright wrote:
> On Fri, 03 Feb 2017 23:24:12 -0800, Ali Çehreli wrote:
> Again, this is for a restricted type of application that I happen to
write
> rather often. And it's restricted to a subset of the application that
> shares very little state with the rest.
I
On Fri, 03 Feb 2017 23:24:12 -0800, Ali Çehreli wrote:
> In practice, both null pointer and range error can probably be dealt
> with and the program can move forward.
>
> However, in theory you cannot be sure why that pointer is null or why
> that index is out of range. It's possible that
On 02/01/2017 06:29 PM, Chris Wright wrote:
> On Wed, 01 Feb 2017 11:25:07 -0800, Ali Çehreli wrote:
>> 1) There is the well-known issue of whether Error should ever be caught.
>> If Error represents conditions where the application is not in a defined
>> state, hence it should stop operating as
On 02/01/2017 01:27 PM, Joakim wrote:
> On Wednesday, 1 February 2017 at 19:25:07 UTC, Ali Çehreli wrote:
>> tl;dr - Seeking thoughts on trusting a system that allows "handling"
>> errors.
>>
>> [...]
>
> Have you seen this long post from last year, where Joe Duffy laid out
> what they did with
On Thursday, 2 February 2017 at 09:14:43 UTC, Paolo Invernizzi
wrote:
On Wednesday, 1 February 2017 at 21:55:40 UTC, Dukc wrote:
On Wednesday, 1 February 2017 at 19:25:07 UTC, Ali Çehreli
Regarding that, I have trought that wouldn't it be better if
it was bounds checking instead of debug vs
On Wednesday, 1 February 2017 at 21:55:40 UTC, Dukc wrote:
On Wednesday, 1 February 2017 at 19:25:07 UTC, Ali Çehreli
Regarding that, I have trought that wouldn't it be better if it
was bounds checking instead of debug vs release what determined
if in contracts are called? If the contract had
On Wed, 01 Feb 2017 11:25:07 -0800, Ali Çehreli wrote:
> 1) There is the well-known issue of whether Error should ever be caught.
> If Error represents conditions where the application is not in a defined
> state, hence it should stop operating as soon as possible, should that
> also carry over to
On Wednesday, 1 February 2017 at 19:25:07 UTC, Ali Çehreli wrote:
Aside, and more related to D: I think this whole discussion is
related to another issue that has been raised in this forum a
number of times: Whose responsibility is it to execute function
pre-conditions?
Regarding that, I
On Wednesday, 1 February 2017 at 19:25:07 UTC, Ali Çehreli wrote:
tl;dr - Seeking thoughts on trusting a system that allows
"handling" errors.
[...]
Have you seen this long post from last year, where Joe Duffy laid
out what they did with Midori?
tl;dr - Seeking thoughts on trusting a system that allows "handling" errors.
One of my extra-curricular interests is the Mill CPU[1]. A recent
discussion in that context reminded me of the Error-Exception
distinction in languages like D.
1) There is the well-known issue of whether Error
28 matches
Mail list logo
