www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Demunging erroneous terminological nomenclatural obfuscations

reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
Ok, I've been consulting Meyer again, and he lists the following:

    "An _error_ is a wrong decision made during the development of a software
system
    A _defect_ is a property of a software system that may cause the system to
depart from its intended behaviour
    A _fault_ is the event of a software system departing from its intended
behaviour during one of its executions."

So, in the spirit of brother(and sister!)-hood, I'd like to float the idea that
we dispense with the term Error entirely, replacing it with Fault.

We have Exception for exceptional conditions, and Fault for faults. There are no
Error classes (and that becomes an enforced convention), so the ambiguity of the
term error is no longer an issue.

Unless Walter had a good reason why not, I'd further suggest that Fault does not
derive from Exception. And then Fault's can be non-recoverable (i.e. one cannot
exit a catch(...Fault) clause without throwing a Fault), and we're all
happy(er),
since no-one's going to get confused.

Thoughts?
Jul 14 2004
next sibling parent Cabal <cabalN05P4M myrealbox.com> writes:
See my other post on the original thread. Re-read Meyer properly. Even
'Faults' can be recoverable - Chapter 7: EXTERNAL_EXCEPTIONS.

I don't have a problem with any of these terms, previously stated or the
ones below. 
I'll say it again - I have a problem with the prescribed response - Die die
die.

Matthew wrote:

 Ok, I've been consulting Meyer again, and he lists the following:
 
     "An _error_ is a wrong decision made during the development of a
     software
 system
     A _defect_ is a property of a software system that may cause the
     system to
 depart from its intended behaviour
     A _fault_ is the event of a software system departing from its
     intended
 behaviour during one of its executions."
 
 So, in the spirit of brother(and sister!)-hood, I'd like to float the idea
 that we dispense with the term Error entirely, replacing it with Fault.
 
 We have Exception for exceptional conditions, and Fault for faults. There
 are no Error classes (and that becomes an enforced convention), so the
 ambiguity of the term error is no longer an issue.
 
 Unless Walter had a good reason why not, I'd further suggest that Fault
 does not derive from Exception. And then Fault's can be non-recoverable
 (i.e. one cannot exit a catch(...Fault) clause without throwing a Fault),
 and we're all happy(er), since no-one's going to get confused.
 
 Thoughts?
Jul 15 2004
prev sibling next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Matthew wrote:
 Ok, I've been consulting Meyer again, and he lists the following:
 
     "An _error_ is a wrong decision made during the development of a software
 system
     A _defect_ is a property of a software system that may cause the system to
 depart from its intended behaviour
     A _fault_ is the event of a software system departing from its intended
 behaviour during one of its executions."
 
 So, in the spirit of brother(and sister!)-hood, I'd like to float the idea that
 we dispense with the term Error entirely, replacing it with Fault.
 
 We have Exception for exceptional conditions, and Fault for faults. There are
no
 Error classes (and that becomes an enforced convention), so the ambiguity of
the
 term error is no longer an issue.
 
 Unless Walter had a good reason why not, I'd further suggest that Fault does
not
 derive from Exception. And then Fault's can be non-recoverable (i.e. one cannot
 exit a catch(...Fault) clause without throwing a Fault), and we're all
happy(er),
 since no-one's going to get confused.
 
 Thoughts?
 
I haven't read Meyer (and probably won't anytime soon) so I'll just ask a couple of questions to get more of the picture: Where does Exception fit into the list? Many applications today, from 3D Studio to GAIM use plugins for much of their features; actually GAIM rely on it. The plugins are dlls implementing some interface. If an fault occurs in a plugin, making it impossible for it to continue operation, then (as long as the plugin don't terminate the appliaction) the fault will propagate up to the main application. Depending on the plugin, the application might decide that the plugin's services aren't needed to operate. Should the application terminate or unload the plugin? Most of today's computer games have some fancy graphics routines relying on really heavy floating point computations. Such computations fail surprisingly often (especially with overclocked computers common among gamers) and might result in an fault if it is detected. For a game system, the only effect might turn out to be a faulty frame. One frame isn't even noticable in the flurry of frames. Should the application (if it knows about the faulty frame at all) terminate, or just go on to the next frame? Why can't the most robust systems, where hardware can be hot plugged and harddrives are in redundant arrays, and backups are everywhere, upon detection of an fault (any conceivable computer related fault (force majeur excepted)) switch the working hardware, rollback to the last backup, and continue? How could a robust OS be written in D if faults where irrecoverable? What faults, if any, exist that cannot be recovered from in some sort of system? In the above definition of faults, nothing is said of invalid states. If the execution of the system deviates from the intended behaviour (which surely only can be known by the system and it's makers, not by Walter or anybody else writing the compiler) it's an fault. A defect search algorithm will lead to a fault if used. The fault is discovered by DbC. Why shouldn't the system be able to retry with some other algorithm that hopefully works? Just wondering. Lars Ivar Igesund PS I might agree with the exception/fault scheme you're proposing, but I don't see any events that should be put in the fault category. If I use a external library, I don't necessarily want to terminate my app just because they decided to throw a Fault. It would reduce the robustness of my app big time.
Jul 15 2004
parent reply "Matthew Wilson" <admin.hat stlsoft.dot.org> writes:
This is an excellent point, and one I'd intended to mention earlier.

An exception (he he) to the rule/practice I advocate is when one is loading
plug-ins. The general philosophy here is for the plug-in host process to
protect itself across the interface layer with the plug-in. I've done this
myself in the pasts, and generally take this approach.

However, it's wrong. Just because the host process can put a catch(...)
across this interface does not mean that, when an exception is caught and
the plug-in unloaded, the process is safe to carry on. It's not. (Note that
catch(...) does not necessarily catch any non-C++ errors, it depends on the
EH specifics of the C++ compiler. IIRC Metrowerks does not catch hardware
errors as C++ errors on Win32; for that, Structured Exception Handling is
required.)

This lesson was learned by MS with IIS, which originally advocated the use
of in-process COM objects (and protected itself across all host/plug-in
interfaces), but still found reliability issues caused it to move to
advocate the out-of-process server model, with the consequent performance
hit (since process launching is expensive in Win32 c/w UNIX).

So, by all means flout the rules - as I've done/do myself - but don't kid
yourself about what you're doing. If you're doing an editor, or something
user-interactive, it's far better to inform the user that a given plug-in
has faulted, and advise them to shut the process asap.



"Lars Ivar Igesund" <larsivar igesund.net> wrote in message
news:cd5uqc$226q$1 digitaldaemon.com...
 Matthew wrote:
 Ok, I've been consulting Meyer again, and he lists the following:

     "An _error_ is a wrong decision made during the development of a
software
 system
     A _defect_ is a property of a software system that may cause the
system to
 depart from its intended behaviour
     A _fault_ is the event of a software system departing from its
intended
 behaviour during one of its executions."

 So, in the spirit of brother(and sister!)-hood, I'd like to float the
idea that
 we dispense with the term Error entirely, replacing it with Fault.

 We have Exception for exceptional conditions, and Fault for faults.
There are no
 Error classes (and that becomes an enforced convention), so the
ambiguity of the
 term error is no longer an issue.

 Unless Walter had a good reason why not, I'd further suggest that Fault
does not
 derive from Exception. And then Fault's can be non-recoverable (i.e. one
cannot
 exit a catch(...Fault) clause without throwing a Fault), and we're all
happy(er),
 since no-one's going to get confused.

 Thoughts?
I haven't read Meyer (and probably won't anytime soon) so I'll just ask a couple of questions to get more of the picture: Where does Exception fit into the list? Many applications today, from 3D Studio to GAIM use plugins for much of their features; actually GAIM rely on it. The plugins are dlls implementing some interface. If an fault occurs in a plugin, making it impossible for it to continue operation, then (as long as the plugin don't terminate the appliaction) the fault will propagate up to the main application. Depending on the plugin, the application might decide that the plugin's services aren't needed to operate. Should the application terminate or unload the plugin? Most of today's computer games have some fancy graphics routines relying on really heavy floating point computations. Such computations fail surprisingly often (especially with overclocked computers common among gamers) and might result in an fault if it is detected. For a game system, the only effect might turn out to be a faulty frame. One frame isn't even noticable in the flurry of frames. Should the application (if it knows about the faulty frame at all) terminate, or just go on to the next frame? Why can't the most robust systems, where hardware can be hot plugged and harddrives are in redundant arrays, and backups are everywhere, upon detection of an fault (any conceivable computer related fault (force majeur excepted)) switch the working hardware, rollback to the last backup, and continue? How could a robust OS be written in D if faults where irrecoverable? What faults, if any, exist that cannot be recovered from in some sort of system? In the above definition of faults, nothing is said of invalid states. If the execution of the system deviates from the intended behaviour (which surely only can be known by the system and it's makers, not by Walter or anybody else writing the compiler) it's an fault. A defect search algorithm will lead to a fault if used. The fault is discovered by DbC. Why shouldn't the system be able to retry with some other algorithm that hopefully works? Just wondering. Lars Ivar Igesund PS I might agree with the exception/fault scheme you're proposing, but I don't see any events that should be put in the fault category. If I use a external library, I don't necessarily want to terminate my app just because they decided to throw a Fault. It would reduce the robustness of my app big time.
Jul 15 2004
parent "Walter" <newshound digitalmars.com> writes:
"Matthew Wilson" <admin.hat stlsoft.dot.org> wrote in message
news:cd6018$236j$1 digitaldaemon.com...
 So, by all means flout the rules - as I've done/do myself - but don't kid
 yourself about what you're doing. If you're doing an editor, or something
 user-interactive, it's far better to inform the user that a given plug-in
 has faulted, and advise them to shut the process asap.
I've had a long discussion about this elsewhere, too, where the others argued that 'Errors' should always abort, and not be catchable. I believe that in a *systems* programming language, this decision should be made by the programmer, not the language. The default behavior is that any exception derived from Error is not caught and terminates the program. If the programmer specifically writes a catch for it, he can. There can be many specialized reasons for doing this. For example, one technique used in garbage collection implementations is to deliberately catch attempts to write to read-only memory. Another reason might be for tracking down a particularly nasty bug. There's a time and a place for flouting the rules, and the language should allow it.
Jul 15 2004
prev sibling parent "Vathix" <vathixSpamFix dprogramming.com> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:cd4m8m$16i4$1 digitaldaemon.com...
 Ok, I've been consulting Meyer again, and he lists the following:

     "An _error_ is a wrong decision made during the development of a
software
 system
     A _defect_ is a property of a software system that may cause the
system to
 depart from its intended behaviour
     A _fault_ is the event of a software system departing from its
intended
 behaviour during one of its executions."

 So, in the spirit of brother(and sister!)-hood, I'd like to float the idea
that
 we dispense with the term Error entirely, replacing it with Fault.
Sounds good.
 We have Exception for exceptional conditions, and Fault for faults. There
are no
 Error classes (and that becomes an enforced convention), so the ambiguity
of the
 term error is no longer an issue.

 Unless Walter had a good reason why not, I'd further suggest that Fault
does not
 derive from Exception.
Good..
 And then Fault's can be non-recoverable (i.e. one cannot
 exit a catch(...Fault) clause without throwing a Fault), and we're all
happy(er),
 since no-one's going to get confused.
I have a little problem with this. Right now, I usually have a last chance catch(Object) if I want to recover from anything, but I put a limit on it; if 10 or so errors occur, bail out of the program. It prevents a possible flood of unrecoverable errors, and lets little slips continue. Your idea would prevent me from doing this, correct? Anything non-Exception would have to be re-thrown. I think it should be up to the programmer. Catching anything that's not an Exception should be considered dangerous, and leave it at that.
 Thoughts?
Jul 15 2004