Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!think.com!linus!linus!emery From: emery@linus.mitre.org (David Emery) Newsgroups: comp.software-eng Subject: Re: error handling techniques? Message-ID: Date: 15 Nov 90 21:04:48 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: usenet@linus.mitre.org Organization: The Mitre Corporation, Bedford, MA Lines: 32 In-reply-to: baeder@shamu.cadence.com's message of 15 Nov 90 16:23:55 GMT 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. Consider errno as a simple example, and look at what can (and often does, if you're not careful) happen (actions happen in "linear order" shown): thread 1 thread 2 fd = open ("afile"); result = open ("not_afile"); /* open fails */ /* errno is EBADF */ if (result) { result = write (fd, buf); /* read fails */ /* errno is EFBIG */ switch (errno) { /* now errno is EBADF, * a value not recognized * as a result from open()!! */ 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. dave emery