The extent of trust in errors and error handling

[Chris Wright via Digitalmars-d]

On Fri, 03 Feb 2017 23:24:12 -0800, Ali Çehreli wrote:
> In practice, both null pointer and range error can probably be dealt
> with and the program can move forward.
> 
> However, in theory you cannot be sure why that pointer is null or why
> that index is out of range. It's possible that something horrible
> happened many clock cycles ago and you're seeing the side effects of
> that thing now.

Again, this is for a restricted type of application that I happen to write 
rather often. And it's restricted to a subset of the application that 
shares very little state with the rest.

> What operations can you safely assume that you can still perform? Can
> you log? Are you sure? Even if you caught RangeError, are you sure that
> arr.ptr is still sane? etc.

You seem to be assuming that I'll write:

  try {
    foo = foo[1..$];
  } catch (RangeError e) {
    log(foo);
  }

I'm actually talking about:

  try {
    results = process(documentName, document);
  } catch (Throwable t) {
    logf("error while processing %s: %s", documentName, t);
  }

where somewhere deep in `process` I get a RangeError.

> Even if you caught RangeError, are you sure that
> arr.ptr is still sane?

Well, yes. Bounds checking happens before the slice gets assigned for 
obvious reasons. But I'm not going to touch the slice that produced the 
problem, so it's irrelevant anyway.