This may have (probably did) existed before vw74, but that's where I
noticed it. If I kept such a list, this would be in my top 20 most
difficult bugs to get to the bottom of in 16 years of Smalltalking.
The attached fileout has two class side methods that print the
originator of a raised exception. One is correct, the other was not
expected. The not unexpected one is nil. The reason it is nil seems
to be because it came from a full block. I raised it from a handler
block, but the same issue happens if you raise an exception from,
say, an ifNotNil: block. The homeReceiver is nil, so the originator
does not get set.
In our case, we probe the originator of some of our Exceptions and if
it is of a certain type we can provide a much richer 'description'.
In some cases, the technique worked. In others, it didn't because the
originator was nil (thus the probe failed). And the difference boiled
down to wether the exception was raised from within a block. A real
block, not a block that looks like a block, but isn't a block because
it's an ifTrue:/ifFalse: construct. They say it's ok to cheat as long
as you don't get caught. But this seems like a catch.
Anyone else ever run across this before?
--
Travis Griggs
Objologist
"Dying men never wish they'd spent more time at the office"
-----------------------------------------
DISCLAIMER: This email is bound by the terms and conditions
described at
http://www.key.net/disclaimer.htm-----------------------------------------
DISCLAIMER: This email is bound by the terms and conditions
described at
http://www.key.net/disclaimer.htm