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?

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?

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.

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.
>

"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?
>
>
>

"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.