View mode: basic / threaded / horizontal-split · Log in · Help
April 13, 2005
Re: recoverable and unrecoverable errors or exceptions
> 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 ... ;)
April 13, 2005
Re: recoverable and unrecoverable errors or exceptions
"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?
April 13, 2005
Re: recoverable and unrecoverable errors or exceptions
"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++ ;-)
April 13, 2005
Re: recoverable and unrecoverable errors or exceptions
"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
April 13, 2005
Re: recoverable and unrecoverable errors or exceptions
"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.
April 13, 2005
Re: recoverable and unrecoverable errors or exceptions
>> 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. 
;) ]
April 13, 2005
Re: recoverable and unrecoverable errors or exceptions
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
April 13, 2005
Re: recoverable and unrecoverable errors or exceptions
>> 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.
April 13, 2005
OT Re: recoverable and unrecoverable errors or exceptions
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.
April 13, 2005
Re: recoverable and unrecoverable errors or exceptions
"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? :-)
2 3 4 5 6 7 8 9 10
Top | Discussion index | About this forum | D home