Tim,
You are correct that it would be better to log the information vs. supressing it entirely. You compiler subclass idea should allow that, and w/o the burden of doing something that has to be adopted by the wider community in order to have remotely lasting value.
I still think that exceptions are an inefficient solution to this particular problem. It strikes me as being similar to using #on:do: to protect #at: when #at:ifAbsent: can suffice. Exceptions of course have the power to "tunnel across the stack," but in this case, I suspect an optional context argument or extension of one that already exists is the preferred approach. #on:do: has overhead even if the exception is not raised, and even more if it is raised. It seems a heavy price to pay when loading large amounts of code.
Bill
Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254
Email: bschwab@anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029
tim@rowledge.org 11/13/2007 2:17 PM >>>
On 13-Nov-07, at 10:50 AM, Bill Schwab wrote:
Tim,
I take exception:
I'll raise your exception...
I don't think you actually want to prevent the error messages (aside from the radical approach that I've always tried to follow - don't make mistakes) as such. Error messages are the weakness leaving the code. Catch it and squeeze it to extract the truthiness for reinsertion.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "Bother" said Pooh, when Piglet stubbed his fag out on the semtex.
_______________________________________________ UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui