I can’t think of a better way to abuse an exception handling mechanism to do conditional logic/control flow instead of fault recovery.
I thought something similarly terrible though, in pseudo-code:
private:
Mutext shared=
new empty();
public:
Resrc takeIfAvail() {
waitThrdHand=this.thrdHandl();
timer=new Thread() {
try {
sleep(3);
}catch(Timeout){
return;
}
kill(waitThrdHand,Timeout);
}
Resrc r;
try{
r=shared.take();
}catch(Timeout){
return null;
}
kill(timer,Timeout);
return r;
}
In English: wait three seconds for a resource to become available. If it isn’t available, give up and return null. Otherwise return the resource. BAM! No more deadlocks ever!
You could write a similar method putResourceIfUnlocked() which fills the mutext with a value if it is open, otherwise gives up after three seconds.
Never Stop Posting 
A nice start, but not good enough for an obfuscation contest.
LikeLike
I take it arithmetic overflow doesn’t cause ArithmeticException in Java?
LikeLike
I can’t think of a better way to abuse an exception handling mechanism to do conditional logic/control flow instead of fault recovery.
I thought something similarly terrible though, in pseudo-code:
private:
Mutext shared=
new empty();
public:
Resrc takeIfAvail() {
waitThrdHand=this.thrdHandl();
timer=new Thread() {
try {
sleep(3);
}catch(Timeout){
return;
}
kill(waitThrdHand,Timeout);
}
Resrc r;
try{
r=shared.take();
}catch(Timeout){
return null;
}
kill(timer,Timeout);
return r;
}
In English: wait three seconds for a resource to become available. If it isn’t available, give up and return null. Otherwise return the resource. BAM! No more deadlocks ever!
You could write a similar method putResourceIfUnlocked() which fills the mutext with a value if it is open, otherwise gives up after three seconds.
LikeLike