[prev] [thread] [next] [lurker] [Date index for 2007/01/29]
On Jan 29, 2007, at 7:00 AM, Andy Armstrong wrote: > I guess you don't like signals / slots or callbacks in general either > then? They're all useful tools. They should all be used with extreme care. Concurrency and asynchrony have to be dealt with somehow, and the tools that have developed to deal with them carry the hatefulness of concurrency around with them. Applying these tools to normal errors (e.g. file not found) is hateful. Exceptions should be reserved for errors that aren't normally recovered from. It should require the equivalent of "#pragma FIXME_THIS_IS_EVIL_CODE" to do anything at the end of an exception handler other than throwing the same exception again. Signals should be reserved for infrequent asynchronous events. Yes, SIGFPE, I'm looking at you. Callbacks should be reserved for asynchronous events, unless you're working in a fully reflective language where they can be used as generators. If you have to define a procedure, signal handler, or callback method for normal return from synchronous code, something is wrong or hateful. > Or closures? I wouldn't class closures in with signals and callbacks, but I've mostly dealt with closures where they're basically generators. It wouldn't surprise me to learn that there's hatefulness lurking there. > They're all to do with the flow of control bouncing around in ways > that weren't explicitly designed into the code that does the transfer > of control. The same is true of "return".There's stuff above here
Generated at 23:01 on 06 Feb 2007 by mariachi 0.52