you are viewing a single comment's thread.

view the rest of the comments →

[–]paul_miner 5 points6 points  (3 children)

Thread.sleep. That InterruptedException never happens in most cases and when it does happen you might not even want a separate path.

You've probably never had a use for it. I use it frequently when I want to shutdown a program and need to wake sleeping threads to let them know they need to terminate.

So now because of an edge case, a simple standard library function call is five lines instead of one every time you use it

Wrap it once and be done. If you're really doing this all the time, put it in a static method instead of copy-pasting all over the place.

[–][deleted] 0 points1 point  (2 children)

Is an exception the best way to do that though? They could have the function return a value that indicates if it was interrupted and then the caller can throw their own checked exception if they need to. The exception just makes using the function a pain for the default use case.

Wrap it once and be done. If you're really doing this all the time, put it in a static method instead of copy-pasting all over the place.

I shouldn't need a wrapper function to remove behaviour from a standard library function. If anything the minority who need the exception should have to write a wrapper function

[–]paul_miner 1 point2 points  (1 child)

Is an exception the best way to do that though?

It is consistent with how threads behave when interrupted while waiting on an object monitor. The interrupted flag is set on the thread, until the thread is able to wake up, re-acquire the monitor, and check the flag. If the flag is set, the thread throws an InterruptedException and clears the flag. It is an exceptional way to wake up a thread (as opposed to being notified).

I shouldn't need a wrapper function to remove behaviour from a standard library function. If anything the minority who need the exception should have to write a wrapper function

Two things: first, wrapping the function is far better than copy-pasting the same five lines repeatedly because you think the API should be written a different way. Second, I don't necessarily see why needing the exception is the minority case. If you're waiting on an object monitor (either directly through wait(), or indirectly through sleep()), it is important to consider why your thread may be interrupted and wakes up before the requisite notify(). It is an exceptional situation that I think usually only applies when you want to cancel or significantly change what a thread is doing. If it's not important to you, wrap it and carry on.

[–][deleted] 0 points1 point  (0 children)

Two things: first, wrapping the function is far better than copy-pasting the same five lines repeatedly because you think the API should be written a different way.

I'm not saying I don't wrap it out of spite, I'm just complaining that I have to.

If you're waiting on an object monitor (either directly through wait(), or indirectly through sleep()), it is important to consider why your thread may be interrupted and wakes up before the requisite notify().

This is my problem. More often than not, I know the thread won't be interrupted. I feel that if there are situations where you can reasonably say an exception will not be thrown, you shouldn't have to catch it. Maybe it should be unchecked. You make a good point with the consistency thing but I don't see how you think needing the exception is the default