Kevin Wampler wrote:
> On 10/22/2010 3:36 PM, Darren New wrote:
>> Kevin Wampler wrote:
>>> On a terrifyingly related note:
>>> http://www.foo.be/docs/tpj/issues/vol2_1/tpj0201-0004.html
>>
>> Excellent! That's a keeper.
>>
> 
> Turns out it's a joke 

Wait. When you posted that, did you *not* think it's a joke?

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

Post a reply to this message

Warp wrote:
>   Of course in practice people don't usually use exceptions for expected
> errors, only for severe ones. 

I don't think it's "expected vs severe", at least not in code where people 
have thought about it. It's more "errors you're likely going to want to 
handle right where they happen (such as not being able to open the file 
you're trying toopen)" vs "errors you likely have a more global catch for 
(such as divide by zero or out of disk space)".

The advantage of the exception mechanism is you can catch a bunch of 
exceptions anywhere in a bunch of called routines with one catch. If the 
type of error is one that 95% of the time I want to handle the error right 
where it happens (like "OK, couldn't open it, so I'll create it" or "I'll 
prompt the user for a different name" or something) then it doesn't make 
sense to code it as an exception.

And I think that's where Java's checked exceptions concept fails: They 
explicitly turn the things you want to test for into exceptions, then 
require you to test for them anyway with a much more tedious and distracting 
syntax.


As for exiting a thread by forcing it to throw an exception, that makes 
perfect sense from an implementation point of view.

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

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> As for exiting a thread by forcing it to throw an exception, that makes 
> perfect sense from an implementation point of view.

  Usually threads are ended by exiting the function that was launched by
the thread...

-- 
                                                          - Warp

Post a reply to this message

On 23/10/2010 06:27 PM, Warp wrote:

>    Usually threads are ended by exiting the function that was launched by
> the thread...

Yes, usually. But the GHC threading implementation allows you to 
forcibly "kill" another thread (by throwing an exception in it, as I say).

It's occasionally useful to do this if the thread performs some kind of 
"infinite loop", and it's another thread's job to detect when the loop 
should be stopped. You could of course just have a semaphore to signal 
to the thread that it should stop now, but if some part of the thread's 
loop takes a long time to execute, it might not be convinient to check 
the semaphore frequently enough that the thread will stop promptly.

(OTOH, I gather GHC cannot kill a thread except at certain points in the 
code, so you can end up with an unkillable thread anyway...)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> As for exiting a thread by forcing it to throw an exception, that makes 
>> perfect sense from an implementation point of view.
> 
>   Usually threads are ended by exiting the function that was launched by
> the thread...

Exactly. So the thread equivalent of "exit()" usually throws an exception 
that's generally outside the usual exception hierarchy, in order to unwind 
the stack and cause the top-most function to exit without screwing up other 
threads.  And most thread libraries for languages with exceptions give you a 
way to make that happen in some other thread.

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

Post a reply to this message

On 23/10/2010 05:39 PM, Darren New wrote:

> I don't think it's "expected vs severe", at least not in code where
> people have thought about it. It's more "errors you're likely going to
> want to handle right where they happen (such as not being able to open
> the file you're trying toopen)" vs "errors you likely have a more global
> catch for (such as divide by zero or out of disk space)".

Makes sense.

> The advantage of the exception mechanism is you can catch a bunch of
> exceptions anywhere in a bunch of called routines with one catch.

True enough.

[In Haskell, exceptions carry the disadvantage that due to lazy 
evaluation, it can be a tad unpredictable exactly when an exception will 
be thrown. Also, you can only catch these exceptions in the IO monad, 
which might be a very, very long way away from where the exception 
happened...]

> And I think that's where Java's checked exceptions concept fails: They
> explicitly turn the things you want to test for into exceptions, then
> require you to test for them anyway with a much more tedious and
> distracting syntax.

Heh, yeah, there is that. In all the Java code I've looked at, I don't 
think I've ever seen a try/catch block which actually *handles* an 
exception. They all just silently ignore it. (Then again, I haven't 
looked at a lot of exception code...)



There's a couple of people on the Haskell mailing lists who like to 
distinguish between "exceptions" and "errors" (and get all shirty when 
people claim that they're the same thing).

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.

For example, division by zero or an invalid array index would be errors. 
(Your program should be constructed such that these never happen for any 
reason.) Trying to open a file that doesn't exist would be an exception. 
(Even if you check that the file exists, it could theoretically cease to 
exist by the time you go to open it.)

Some people have even gone as far as to suggest that it's a design flaw 
that errors can be caught. But of course, if it were not so then a mere 
coding glitch could crash a production system with no possibility of 
exiting gracefully, closing resources properly, logging what happened, 
or maybe, I don't know, restarting the failed operation?

(Ideally your program shouldn't contain any bugs. But if the program is 
critical enough, you really don't want it to just shut down because 
something bad happened. You might want to have it reset itself and try 
again - assuming that this is likely to produce a different result of 
course.)

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? :-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

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

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

I'm not quite sure what to make of that, other than "people have 
different terms for things".

Then again, this is from the community where "parallel" and "concurrent" 
aren't the same thing...

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

Well, yeah, there is that. This is Haskell, after all. *sigh*

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

It just amuses me that if you have a single-threaded program that throws 
an exception, the program halts and prints out a message on stderr. But 
as soon as you have multiple threads... this doesn't happen any more.

You'd think it would make more sense to rethrow an uncaught exception to 
thread #0, but anyway...

The GHC threading implementation also lacks things like being able to 
assign priorities to threads, and so forth. But hey, at least it works.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:
> I'm not quite sure what to make of that, other than "people have 
> different terms for things".

Sure.

> Then again, this is from the community where "parallel" and "concurrent" 
> aren't the same thing...

They aren't.

> It just amuses me that if you have a single-threaded program that throws 
> an exception, the program halts and prints out a message on stderr. But 
> as soon as you have multiple threads... this doesn't happen any more.

I see.

> You'd think it would make more sense to rethrow an uncaught exception to 
> thread #0, but anyway...

No, because there's no reasonable context in thread 0 to which you could 
throw the exception. If you want to catch the exception, catch it in the 
thread where it happened.  It's perfectly reasonable, given how threads are 
usually defined as "run this function in a separate thread", which makes it 
trivial to wrap whatever in a top-level function that catches and handles 
otherwise-uncaught exceptions.

The fact that the program doesn't stop when the thread doesn't catch an 
execption is exactly why you kill threads from outside by coaxing them into 
throwing an exception.

> The GHC threading implementation also lacks things like being able to 
> assign priorities to threads, and so forth. 

That's a whole 'nuther can of worms.

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

Post a reply to this message

On 10/23/2010 9:31 AM, Darren New wrote:
>
> Wait. When you posted that, did you *not* think it's a joke?
>

I had heard the story from a friend (told not as a joke) and had only 
skimmed a few paragraphs the article to see that it was indeed the one 
they were talking about, so yes.  I also think the friend had never read 
the article, but had heard the story from some one else.  I'm sure some 
urban legends have started that way.  Upon actually reading the article, 
yeah, it's quite obvious that it's not real.

Post a reply to this message