From: Magentus <mag...@gm...> - 2008-11-26 12:58:37
|
On Tue, 25 Nov 2008 17:56:54 +0200, Twylite <tw...@cr...> wrote: > Sadly it will be some time before I can gain value from this function > myself. Not until the third-party libraries I am tied to - which > require me to parse the (non-localised) result - are updated to > produce an errorcode. Not until I find enough time on or between > projects to refactor legacy code (core libraries that I depend on and > use in pretty much all new utilities and applications) to use > errorcode rather than (or, for backwards compatibility, in addition > to) a list structure in the result. Not in places where I need to > maintain code that allocates & frees more than 2 resources, which can > be done cleanly using finally callbacks, but otherwise sends you to > the depths of nested try/finally blocks and you can't see the wood for > the error-and-cleanup-handling trees. THIS is the part I've been trying to deal with. - Support for all current return values, not just one limited view of reality, so that it's useful NOW, not some time in an unknown future that may or may not happen. (That's what happened to errorcode, it was created before the mechanisms existed to make good use of it, and it's floundered in obscurity ever since.) - And for cleaning up those messes of switch and other statements presently needed to support all kinds of error and result handling. If done right, it'll be fast and efficient for the simple case. And a heck of a lot easier to read and work with in the complex case. Especially when it's so damn simple trivial to do so much better. -- Fredderic Debian/unstable (LC#384816) on i686 2.6.23-z2 2007 (up 49 days, 6:43) |