> Customers don't like programs crashing. In practice many errors - even many asserts - are not fatal and can be recovered from.

Do you mean pure crashes? Or do you mean crashes and/or orderly shutdowns?

If the latter, I'd suggest that that might still be due to the fact that they're not used to them.

>> This is made even worse with people getting filthy rich peddling blatantly inferior programs and "operating systems". Programmers, and especially the pointy haired bosses, have a hard time becoming motivated to do things Right.
>
> I assume you are talking about Windows. There are many pressures on software companies. I won't defend Microsoft's decisions but I doubt that if they had made Windows crash "harder" than it did that they would have been more motivated to fix bugs. They had a different measure of release criteria than we do today.

Very true. I too doubt that some sectors of our industry would benefit from IZT.

But that's politics and commerce, which is *way* outside my area of expertise.

Seriously, though, don't we think it'd be nice if D made, or supported, serious advances in such areas? Kind of like a beam of light ... ;)

"Matthew" <admin@stlsoft.dot.dot.dot.dot.org>
> Seriously, though, don't we think it'd be nice if D made, or supported, serious advances in such areas? Kind of like a beam of light ... ;)

It would. But please get in line behind "reduction of maintenance costs". That would also be a beam of light; and one dispensing lots of dollar bills :-)

Pet peeves aside: I suspect the issue here is 'Forced Adoption', and not the IZT concept itself (although one might argue they are hand-in-glove?). I'm told you can't force religion upon anyone, anymore. Is that true?

"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:d3i1p2$m2b$1@digitaldaemon.com...
>> Customers don't like programs crashing. In practice many errors - even many asserts - are not fatal and can be recovered from.
>
> Do you mean pure crashes? Or do you mean crashes and/or orderly shutdowns?
>
> If the latter, I'd suggest that that might still be due to the fact that they're not used to them.

I wasn't making a distinction - though if an orderly shutdown includes simply printing the warning "you might want to save relevant data and quit" then I'm all for that :-)

>>> This is made even worse with people getting filthy rich peddling blatantly inferior programs and "operating systems". Programmers, and especially the pointy haired bosses, have a hard time becoming motivated to do things Right.
>>
>> I assume you are talking about Windows. There are many pressures on software companies. I won't defend Microsoft's decisions but I doubt that if they had made Windows crash "harder" than it did that they would have been more motivated to fix bugs. They had a different measure of release criteria than we do today.
>
> Very true. I too doubt that some sectors of our industry would benefit from IZT.
>
> But that's politics and commerce, which is *way* outside my area of expertise.
>
> Seriously, though, don't we think it'd be nice if D made, or supported, serious advances in such areas? Kind of like a beam of light ... ;)

yup. I wonder ... if Walter writes a D++ compiler in D would it take as long as writing a D compiler in C++ ;-)

"Kris" <fu@bar.com> wrote in message news:d3i31n$n1s$1@digitaldaemon.com...
> "Matthew" <admin@stlsoft.dot.dot.dot.dot.org>
>> Seriously, though, don't we think it'd be nice if D made, or supported, serious advances in such areas? Kind of like a beam of light ... ;)
>
> It would. But please get in line behind "reduction of maintenance
> costs".
> That would also be a beam of light; and one dispensing lots of
> dollar bills
> :-)

Another worthy cause. No argument from me there.

> Pet peeves aside: I suspect the issue here is 'Forced Adoption',
> and not the
> IZT concept itself (although one might argue they are
> hand-in-glove?).

Yes, I very much suspect the same thing.

> I'm told you can't force religion upon anyone, anymore. Is that true?

 Perhaps one more adroit in conflict resolution than me can see a
way through this. (Of course, even when we've battled ourselves
through leagues of wolf-infested forests we will then have to swim
through the infinite see of WhatMess? and then throw ourselves on
the impassive walls of Walter's keep of GoodEnough.)

Charon the Invaliant

"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:d3i392$n89$1@digitaldaemon.com...
>
> "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:d3i1p2$m2b$1@digitaldaemon.com...
>>> Customers don't like programs crashing. In practice many errors - even many asserts - are not fatal and can be recovered from.
>>
>> Do you mean pure crashes? Or do you mean crashes and/or orderly shutdowns?
>>
>> If the latter, I'd suggest that that might still be due to the fact that they're not used to them.
>
> I wasn't making a distinction - though if an orderly shutdown includes simply printing the warning "you might want to save relevant data and quit" then I'm all for that :-)

Includes or comprises? Certainly it would include that (for GUI apps). But it would comprise that + shutting down. I'm not 100% sure that's what you meant.

>>>> This is made even worse with people getting filthy rich peddling blatantly inferior programs and "operating systems". Programmers, and especially the pointy haired bosses, have a hard time becoming motivated to do things Right.
>>>
>>> I assume you are talking about Windows. There are many pressures on software companies. I won't defend Microsoft's decisions but I doubt that if they had made Windows crash "harder" than it did that they would have been more motivated to fix bugs. They had a different measure of release criteria than we do today.
>>
>> Very true. I too doubt that some sectors of our industry would benefit from IZT.
>>
>> But that's politics and commerce, which is *way* outside my area of expertise.
>>
>> Seriously, though, don't we think it'd be nice if D made, or supported, serious advances in such areas? Kind of like a beam of light ... ;)
>
> yup. I wonder ... if Walter writes a D++ compiler in D would it take as long as writing a D compiler in C++ ;-)

Not clear. Are you being cute? If you're pointing out that a D++
compiler written in D would take less time (and presumably be more
robust) than in C++, then I'd have to say:
    (i) that's conjecture, albeit I agree it's probably right
    (ii) that's but one small application area. If D is _only_
superior as a development technology to C++ in writing compilers,
it's not going to set many new standards.

D's promise is great but its problems are considerable, and it seems like suggestions for improvements - not just talking about my own, mind - are rarely embraced. It's like contentment rules, and yet, despite so much to hope for, there's little to be content about.

>> If you want, I'll have a root around my code base for another in
>> a
>> bit ...
>
> No need, this is fine, thank you.
>
> One important point is that I'm not recommending the removal of the CP  violation, quite the opposite, but, I believe that the programmer should  be able to make the informed decision about whether it's terminal or not.

Ok. My understanding of your position is that that decision is rightly within the purview of the programmer of a component's client code, whereas I'm saying that (at least in principle) it can only be within the purview of the component's programmer.

Is that a fair characterisation of our respective positions?

> In your example, the best course was/is to terminate, as it's main goal/purpose cannot be achieved without significant risk of corruption.

Yes, but I'd rephrase to say "only" course, since there is not, in principle, any other valid course.

> In another example, the plugin one, the main program can continue, it's  main goal/purpose can still be achieved without significant risk of  corruption. (assuming here the plugin is non-essential to it's main goal).

In practice, likely in most cases. In principle no. [Sorry to keep pointing out both parts, but I feel that it's necessary to keep that distinction out there.]

> It comes down to the priority of the task that has asserted, if it's low  priority then given circumstances it's concievable that the programmer may  want to log it, and continue, so as to achieve his/her main priority.  There is risk involved, but it's admittedly small.

By priority do you mean the 'importance' of the user's activities? If so, I agree that that has merit, but it once again takes us back to the

I use GVIM when I'm not plodding along inside VS98. Let's say that GVIM has a bug that, once encountered, causes it to wink off into the aether every 100-200 runs. Most times I am writing very small scripts (usually a file manipulation in Ruby using recls/Ruby), and could certainly live with them disappearing mid-save very few hundred runs. However, some times I'm writing very large makefile generator templates, and were GVIM to lose that, even at such a low frequency, would be a massive hit.

[NOTE: GVIM's never had any kind of crash, or any other bug that I've ever used. It's great! (Although I wish I could find out how to get it to remember the last frame size, so I don't have to resize it every time)]

Now, if the decision on how to deal with bugs were with the GVIM programmer, and they opted for quenching those errors, then it's quite likely that I'd lose some very important work. Conversely, if IZT were in use then it's _not_ the case that I'd have to shutdown when I don't want to all the time: the bug wouldn't exist! GVIM users would have fed back the behaviour to the GVIM author and it'd've been fixed, and I'd never see it. (Since I do never see it, I suspect GVIM might be using IZT already <g>)

If the decision was to leave it to the user, then we wouldn't lose work, but the problem may well persist, and we'd be clicking Continue buttons every few hours. Not terrible, but not good ether. And it'd still kill us with big complex edits anytime we instintively clicked Continue followed by the 1/200 wink. :-(

>>> Basically I'm asking:
>>> 1- What are the causes of contract violations?
>>
>> Whatever the programmer dictates.
>
> Not contract conditions, those the programmer dictates. I want to
> know  what can cause a contract to be violated, I was thinking:
>  - buggy algorithm
>  - memory corruption
> ..

No, it really _is_ just whatever the programmer decides. Only they can know (or help to define) what constitutes a buggy algorithm, a class invariant, even a memory corruption. (Although the OS can determine some memory corruptions, such as accessing an unmapped page, or attempting to write to a read-only page, or what not. But in general there's no overarching help from hardware or anything to be had for compiled languages.)

>>> 2- How many of those would corrupt the "main program" if they occured in a  plugin/module.
>>
>> Impossible to determine. In principle all do. In practice
>> probably a
>> minority. (Bear in mind that just because the numbers of
>> incidence
>> are likely to be low, its not valid to infer that the
>> ramifications
>> of each corruption will be similarly low.)
>
> I agree. Incidence is low, the ramifications may be large. But they may  not be, in which case let the programmer decide.

Wearing the hat of flexibility for a moment, I still don't see how it's the choice of the programmer (of the application, not the plug-in).

What's happened is that the programmer of a plug-in has reified, in executable tests, the design of their code. When one of those tests fires, it communicates to the process within which it resides that it has now acted outside of its design. There are now several options:

    - the plug-in calls abort() and terminates the process
    - the plug-in throws an exception/error

With that error/exception:
    - the process calls abort()
    - the process shuts down, taking appropriate graceful steps,
e.g. telling the user it's saved their work / offering the user the
option to save the work / dumping server context to a log
    - the process, if a GUI app, gives the user the choice of what
to do
    - the process unloads the offending plug-in and continues
executing

>>> The point I am driving at is that a very small subset of
>>> contract
>>> violations corrupt the main program in such a way as to cause it
>>> to crash,
>>
>> May I ask on what you base this statement?
>
> On the comments you and I have made about the likelihood of memory corruption, which, so far, appears to be the only one that causes an  undetectable/handleable crash.

Ok. There are lots more, of course, such as premature release of system resource (window handles, TSS keys, etc.etc)


>>> That would be nice, but it's not required. The choice is in the hands of  the programmer, not the user. If the user doesn't like the choice made by  the programmer, they'll stop using the program.
>>
>> They sure will. But they may've been seriously inconvenienced by
>> it,
>> to the detriment of
>
> ... ? thier business, health, bank account.

Eep. Lost my thread. :$


>>>> Of course we live in a world of mendacity motivated by greed,
>>>> so
>>>> your manager's going to have you water down that dialog faster
>>>> than
>>>> you can "gorporate creed". In which case, we should all just
>>>> violate
>>>> away. (But I believe that most engineers care about their
>>>> craft,
>>>> and
>>>> would have trouble sleeping in such circumstances.)
>>>
>>> Principle/Ideal vs Reality/Practice it's a fine line/balance,
>>> one
>>> that is  unique to each situation and application. Thus why we
>>> cannot mandate  program termination. But, by all means, provide
>>> one in the library.
>>
>> We can't, because D does not have the facilities to do so.
>
> You cannot "enforce" or "mandate" it, but you can "provide" it.

Not sure what you mean? Legally/morally/technically? It's all doable.


>>>>>> Since D is (i) new and open to improvement and (ii) currently
>>>>>> not
>>>>>> capable of supporting irrecoverability by library, I am
>>>>>> campaigning
>>>>>> for it to have it built in.
>>>>>
>>>>> I'd prefer an optional library solution. For reasons expressed
>>>>> in
>>>>> this  post/thread.
>>>>
>>>> So would I, but D does not have the mechanisms to support that,
>>>> so
>>>> it needs language support.
>>>
>>> I assume you're referring to the fact that you can catch Object.
>>> IMO  catching object is an advanced technique. Once the
>>> Exception
>>> tree is  sorted out people will be catching "Exception" if they
>>> want to catch  "everything" and that won't include asserts and
>>> other contract violations.
>>>
>>> This will leave the _possibility_ of catching Object if desired and all  will be happy.
>>
>> What's the merit in catching Object? I just don't get it.
>>
>> Does anyone have a motivating case for doing so?
>>
>> Does anyone have any convincing experience in throwing
>> fundamental
>> types in C++? IIRC, the only reason for allowing it in the first
>> place was so that one could throw literal strings to avoid issues
>> of
>> stack existentiality in early exception-handling infrastructures.
>> Nowadays, no-one talks of throwing anything other than a
>> std::exception-derived type, and with good reason.
>>
>> Leaving it as Object-throw/catchable is just the same as the situation with the opApply return value. It's currently not being abused, so it's "good enough"! :-(
>
> Well, personally I don't care what it's called, I just want to be able to  catch everything, including Assertions etc.

Again, no-one's talking about anything not being catchable. It's whether the caught exception is then rethrown or not. I assume you mean you want to be able to catch and quench everything.

> I'm happy with it being  uncommon, eg.
>
> Object <- not throw/catch-able
>   Throwable
>     Assertion
>     Exception
>        ..etc..
>
> you dont catch Throwable generally speaking, only Exception.

yes, that's along the lines I'm thinking. Being able to catch Object just seems like a loophole with no upside, just like C++'s catching of fundamental types.


>>>> Again it boils down to two things, the theoretical "what do you expect of your software once it's operating outside its design?"
>>>
>>> If it *is* operating outside it's design you cannot expect anything from  it.
>>>
>>> However, (assuming plugin/main context) you cannot know that it
>>> (main  program) *is* operating outside it's design, it only
>>> *might* be (if the  plugin has corrupted it).
>>
>> I don't think it's divisible. If the program has told you it
>> might
>> be operating outside its design, then it is operating outside its
>> design.
>
> Not if it's design includes trying to handle that situation.
>
>> After all, a program cannot, by definition, be designed to work with a part of it that is operating outside its design.
>
> Why not?
>
>> How
>> could the interaction with that component be spelt out in design,
>> never mind codified?
>
> if (outside_design) component = disabled;
> if (component == disabled) return ;

The program itself cannot be designed to work with something it's not designed to work with. It's axiomatic.

>>>> and
>>>> the practical "wouldn't you like to use software that's been
>>>> subject
>>>> to a highly fault-intolerant design/development/testing
>>>> methodology?"
>>>
>>> Of course. But that does not mean I agre with mandatory program termination.
>>>
>>>> There's simply no getting away from the first
>>>
>>> Indeed.
>>
>>
>> btw, I think we've covered most of the stuff now. I'm happy to
>> continue if you are, but equally happy to let the group decide
>> (that
>> irrecoverability is not worth having ;< )
>
> Ok, lets leave it here then. I'll leave the comments I've just made, feel  free to ignore them :)

LOL. I should have read to the end first. Well, hrumph, I'm not wasting all that typing, so here it is.

[If you wish, just post a "Last Word" and I promise not to top it. ;) ]

On Wed, 13 Apr 2005 13:46:47 +1000, Matthew <admin@stlsoft.dot.dot.dot.dot.org> wrote:
>>> If you want, I'll have a root around my code base for another in
>>> a
>>> bit ...
>>
>> No need, this is fine, thank you.
>>
>> One important point is that I'm not recommending the removal of
>> the CP  violation, quite the opposite, but, I believe that the
>> programmer should  be able to make the informed decision about
>> whether it's terminal or not.
>
> Ok. My understanding of your position is that that decision is
> rightly within the purview of the programmer of a component's client
> code, whereas I'm saying that (at least in principle) it can only be
> within the purview of the component's programmer.
>
> Is that a fair characterisation of our respective positions?

Yep.

>>> btw, I think we've covered most of the stuff now. I'm happy to
>>> continue if you are, but equally happy to let the group decide
>>> (that
>>> irrecoverability is not worth having ;< )
>>
>> Ok, lets leave it here then. I'll leave the comments I've just
>> made, feel  free to ignore them :)
>
> LOL. I should have read to the end first. Well, hrumph, I'm not
> wasting all that typing, so here it is.
>
> [If you wish, just post a "Last Word" and I promise not to top it.
> ;) ]

Resisting the urge to post something controversial to test this promise .. done!

Regan

>> I wasn't making a distinction - though if an orderly shutdown includes simply printing the warning "you might want to save relevant data and quit" then I'm all for that :-)
>
> Includes or comprises? Certainly it would include that (for GUI apps). But it would comprise that + shutting down. I'm not 100% sure that's what you meant.

Forcing shutdown is annoying. As long as you tell the user what happened and how serious it could be who are we to quit their app? (though honestly I hope we don't start this whole thread over again) In some sense for the user it's like when Windows tells you at some point you have to reboot after an install (well... not all installs but you know what I mean). Windows doesn't pop up a dialog that says "Reboot?" that just has an OK button. Error recovery should inform the user but let them decide what to do - or worst case let the application developer decide.

>>> Seriously, though, don't we think it'd be nice if D made, or supported, serious advances in such areas? Kind of like a beam of light ... ;)
>>
>> yup. I wonder ... if Walter writes a D++ compiler in D would it take as long as writing a D compiler in C++ ;-)
>
> Not clear. Are you being cute?

Tried to be cute (hence the wink). I was poking fun at Walter for taking so long to finish D.

Matthew wrote:
> [NOTE: GVIM's never had any kind of crash, or any other bug that I've ever used. It's great! (Although I wish I could find out how to get it to remember the last frame size, so I don't have to resize it every time)]
> 
[snip]

I wrote the following lines in $VIM/_vimrc to set up the window size:

winpos 0 0
set lines=53
set columns=166

This is of course not a remember-the-last-frame-size solution, but you
might find it useful.

"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:d3i5dn$oda$1@digitaldaemon.com...
>>> I wasn't making a distinction - though if an orderly shutdown includes simply printing the warning "you might want to save relevant data and quit" then I'm all for that :-)
>>
>> Includes or comprises? Certainly it would include that (for GUI apps). But it would comprise that + shutting down. I'm not 100% sure that's what you meant.
>
> Forcing shutdown is annoying. As long as you tell the user what happened and how serious it could be who are we to quit their app? (though honestly I hope we don't start this whole thread over again)

Agreed.

> In some sense for the user it's like when Windows tells you at some point you have to reboot after an install (well... not all installs but you know what I mean). Windows doesn't pop up a dialog that says "Reboot?" that just has an OK button. Error recovery should inform the user but let them decide what to do - or worst case let the application developer decide.

Actually, some things do. I think Norton Anti Virus just puts an ok button and nothing else. Needless to say I have an running the background that detects this and kills the window without rebooting. Damn! Did I just shoot down my own thesis? :-)