![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> Darren New <dne### [at] san rr com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |