Re: Strategies with SPARK which does not support exceptions

[Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de>]

On 6/29/10 10:05 PM, Randy Brukardt wrote:

> Result codes are dangerous, as ignoring of result codes is one of the major
> problems in programming, and the resulting bugs are very, very hard to find.
> (That's because of the difficulty of finding errors of omission.)
>
> Perhaps you are too young to remember, but early versions of Windows (3.0,
> 3.1) had a reputation for being unstable and crashing often. But the
> problems were mostly not with Windows but rather with programs that tended
> to ignore the error returns from the Windows API.

The result code situation in Windows 6.0 (Vista) seems even
worse today, even inside Windows OS software. The example is
this: When a file in NTFS is encrypted (green in explorer) and an
existing program tries to open it (not knowing that it might be
encrypted), the system returns "Access Denied".  MS says that they
don't have the OS return a more descriptive code because they know that
many old programs will start failing and behave erratically:
the old programs are not prepared to handle return codes that did
not exist when the program was written.

I Learned this when trying to install driver files extracted from
a recent official ZIP archive by Linksys/Cisco, using Windows's own
driver installation program. The files had ended up encrypted in
the file system. Windows's standard installation stops with
"Access Denied" ...



Georg