Over the last few days, I have been getting weird errors from various programs I run on Windows 7. Programs would just fail, or produce corrupt output (I'm looking at you, Windows Moviemaker).

I have a 128Gb SSD drive for my system drive, for speed, and a 4T secondary spinning drive for storage. I knew I was getting nearly out of space on the SSD drive, and had a 256Gb SSD drive ready to swap in.

To migrate the system to the new disk, the idea was to use Windows Backup/Restore of the image. Unfortunately, Windows Backup would get a ways through the process, then fail with no message beyond an error code. Googling the error code produced a vast number of results, and various schemes for fixing it, some official, some not. None of them were applicable. Many involved loading new drivers, editting the system registry, and all sort of unappealing "solutions".

Then I thought, hmm, maybe it's running out of space for temporary files.

I deleted a few gigs, tried again, and it worked fine! I transferred to the new disk, had lots of free gigs, and suddenly the various programs that were experiencing mysterious failures all started working properly.

What I'm pretty sure is happening is those programs use error codes for error reporting, and then don't check the error codes. This is common practice for C code. I'm a little surprised that with Windows' long history, it still has problems detecting when it runs out of disk space.

However, if exceptions are thrown for errors instead, the programmer has to deliberately add code if he wishes to ignore the error.

On 1/11/2015 2:48 AM, Walter Bright wrote:
> To migrate the system to the new disk, the idea was to use Windows
> Backup/Restore of the image. Unfortunately, Windows Backup would get a ways
> through the process, then fail with no message beyond an error code. Googling
> the error code produced a vast number of results, and various schemes for fixing
> it, some official, some not. None of them were applicable. Many involved loading
> new drivers, editting the system registry, and all sort of unappealing "solutions".


BTW, the error code I got from Windows Backup is 0x80070002. Backup's suggestion for what to do next was to run it again (!). Geez.

What is your opinion of approach advertised by various functional languages and now also Rust? Where you return error code packed with actual data and can't access data without visiting error code too, compiler simply won't allow it.

On Sun, 11 Jan 2015 13:06:26 +0000
Dicebot via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> What is your opinion of approach advertised by various functional languages and now also Rust? Where you return error code packed with actual data and can't access data without visiting error code too, compiler simply won't allow it.
from my POV it trashes logic with error checking. hey, i don't care if
*each* `fwrite()` is successfull, i only care if all of them are ok or
at least one (any one) failed!

by the way: how many peope put checks for `close()`/`fclose()` return
value? it returns no actual data, so why bother...

i believe that exceptions are better for error checking: it's hard to ignore errors, error handling logic is clearly separated and so on.

On 1/11/15, Dicebot via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> What is your opinion of approach advertised by various functional languages and now also Rust? Where you return error code packed with actual data and can't access data without visiting error code too, compiler simply won't allow it.

Or a @noignore attribute. Just having that alone could easily catch the mistake of ignoring a return value. I'm really rooting for this, but is anyone else on board?

On 1/11/15, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
> Or a @noignore attribute. Just having that alone could easily catch the mistake of ignoring a return value. I'm really rooting for this, but is anyone else on board?

Or perhaps to avoid keyword/attribute bloat, a -noignore switch.

On Sun, 11 Jan 2015 14:32:21 +0100
Andrej Mitrovic via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On 1/11/15, Dicebot via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> > What is your opinion of approach advertised by various functional languages and now also Rust? Where you return error code packed with actual data and can't access data without visiting error code too, compiler simply won't allow it.
> 
> Or a @noignore attribute. Just having that alone could easily catch the mistake of ignoring a return value. I'm really rooting for this, but is anyone else on board?
`if (myfunc()) {}` ;-) it's still easier than
`try myfunc() catch (Exception) {}`.

this is a question of "opt-in" versus "opt-out". i believe that ignoring errors should be "opt-in", not vice versa. and unhandled error MUST bomb out the app.

to not let ranges succumb to such a problem I wrote: https://github.com/D-Programming-Language/phobos/pull/2724

On Sunday, 11 January 2015 at 13:25:59 UTC, ketmar via Digitalmars-d wrote:
> On Sun, 11 Jan 2015 13:06:26 +0000
> Dicebot via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> What is your opinion of approach advertised by various functional languages and now also Rust? Where you return error code packed with actual data and can't access data without visiting error code too, compiler simply won't allow it.
> from my POV it trashes logic with error checking. hey, i don't care if
> *each* `fwrite()` is successfull, i only care if all of them are ok or
> at least one (any one) failed!

This is where monads and applicatives shine. You can describe the general logic (run 'till first error or collect and combine all errors or something else) in one place and then apply this way of error handling throughout with minimal code, and you can often change the error handling approach later just by changing a type, without editing actual function source code.

On 1/11/2015 5:06 AM, Dicebot wrote:
> What is your opinion of approach advertised by various functional languages and
> now also Rust? Where you return error code packed with actual data and can't
> access data without visiting error code too, compiler simply won't allow it.

It's a great question. I have a lot of experience with error codes, and with exceptions. I have zero with the packed scheme, though that doesn't stop me from having an opinion :-)

Perhaps I misunderstand, but given A calls B calls C,

   A => B => C

and C detects an error, and A knows what to do with the error. B then becomes burdened with checking for the error, invoking some sort of cleanup code, and then propagating it.

Wouldn't this be uglifying B's source code?

With exceptions, C throws, A catches, and B's cleanup happens automatically.

This matters very much for pipeline style programming (i.e. ranges and algorithms).