Orchid XP v8 wrote:
> As far as I can tell, an "error" is a situation that arises due to a bug 
> in your program, whereas an "exception" is when a situation is caused by 
> external events that you can't control.

Huh. I would say an error is something you don't want to have happen, and an 
exception is a data structure describing an alternate return value from a 
function. If this is really how it's worded, then there's definitely a 
problem of crossing meta boundaries.

Ada of course has standard terms for all these sorts of things. The only one 
I remember offhand is "erroneous execution", which means doing something at 
runtime that isn't defined by the language as being checked by the runtime, 
like accessing heap memory that you've already freed and so on.

> For example, division by zero or an invalid array index would be errors. 

In some languages, it's perfectly reasonable to use the 
array-index-out-of-bounds exception to exit your loop when you're done 
processing. Or, at least, you could do it that way intentionally if you want.

In C# event handlers, there's usually a "XYZing" event handler and an 
"XYZed" event handler. So if you want to change the volume, you'd have
   audiothing.Volume = 50
That would invoke the VolumeChanging event, to let anyone interested in the 
volume level know that someone is *trying* to change the volume. If none of 
them throw an exception, it sets the new volume, adjusts the hardware and 
all, then invokes the VolumeChanged event to let everyone know it has 
changed, none of which are *supposed* to throw errors.  If you want to stop 
someone from changing the volume at this particular moment (think grabbed 
focus or something) then you throw an exception in a routine hooked to the 
...ing event.

And of course Eiffel also has a whole mechanism that involves throwing 
exceptions when you have errors. And the first routine with the ability to 
catch the exception depends on the type of error it is.

> Some people have even gone as far as to suggest that it's a design flaw 
> that errors can be caught. 

Yes, only in an academic environment, tho. :-)

> Amusing thing: Last time I checked, a GHC program exits when thread #0 
> exits. And if (say) thread #13 throws an exception which isn't caught, 
> then thread #13 just exits, and the rest of the system keeps running. 
> Isn't that fun? :-)

That's pretty much how most systems with threads work, as far as I know. 
Some have a mechanism that waits for all threads that aren't "background" 
threads to exit, tho, if that's what you mean, but that just means that 
there's a blob of code at the end of Thread#0 that says "iterate thru all 
non-background threads and wait for them to exit."

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message