Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!sdd.hp.com!apollo!perry From: perry@apollo.HP.COM (Jim Perry) Newsgroups: comp.software-eng Subject: Re: error handling techniques? Message-ID: <4e0c391a.20b6d@apollo.HP.COM> Date: 16 Nov 90 21:21:00 GMT References: <1990Nov2.205831.23696@elroy.jpl.nasa.gov> <1990Nov3.153643.26368@clear.com> <286@dcsun21.dataco.UUCP> <28078@usc> <1990Nov15.162355.23151@cadence.com> Sender: root@apollo.HP.COM Reply-To: perry@apollo.HP.COM (Jim Perry) Organization: Hewlett-Packard Company, Apollo Division; Chelmsford, MA Lines: 33 In article emery@linus.mitre.org (David Emery) writes: >One of the major problems with stack-based error systems (and with >Unix errno) is that they don't work in a multi-threaded environment. > [example deleted] >This has been discovered (and rediscovered) by people writing >multitasking Ada programs on Unix, as well as by people using various >C threads packages. This is one of the major reasons that the POSIX >Ada binding uses exceptions rather than errno. The alternative is to >keep errno (or the error stack) as thread/task-specific data, but that >gets messy. In general, it's a good argument against keeping error >information as state, rather than returning it when a function call >returns, particularly when designing software packages that might be >called from Ada or other concurrent systems. Good point, but if you're writing code intended to be thread-safe under UNIX you have to assume that the system beneath you supports you; in particular you either have to know that the threading system task-swaps errno, or be very careful in all contexts that require access to it, e.g. copying it to a thread-local shadow yourself (under a mutex lock). The latter of course does get messy, but by the same token if you're trying to be thread-safe in a world where you can't trust the environment (malloc for one is not generally reentrant), you're going to be doing messy code (or at least reinventing wheels). On the whole UNIX is currently hostile to multithreaded packages on many fronts. I agree, errno was/is not a particular far-sighted mechanism, but it's probably late in the game to start expecting write() to throw exceptions (and I far prefer exceptions to passing error information up and down on function calls). - Jim Perry perry@apollo.hp.com HP/Apollo, Chelmsford MA This particularly rapid, unintelligible patter Isn't generally heard, and if it is it doesn't matter!