Semantics of error() vs halide_assert() in runtime code aren't clear enough

[steven-johnson]

To report errors correctly when writing runtime code, you must be pretty familiar with some internals that aren't obvious enough to a newcomer to the code; we should do something to make this more obvious. The current situation:

• halide_assert() should be used only for unrecoverable failures; it always calls halide_abort().
• error() should be used for potentially recoverable errors
  • Since it calls halide_error(), which may-or-may-not-return depending on the client, calls to error() in the runtime must also return an error code; this is an easy thing to omit. Is there a way we can enforce this syntactically?

[jlaxson]

Maybe part of this can be an additional macro like

#define halide_soft_assert(ctx, retval_if_fails, assert_body) \
  if (!(assert_body)) { \
    error(ctx) << #assert_body; \
    return retval_if_fails; \
  }

So there's an easy outlet for assertion-like behavior that need not necessarily abort.

[steven-johnson]

As a general coding style, the Halide team prefers to avoid macros-with-hidden-control-flow like this (ie, things that hide returns), so that specific suggestion may not fly, but maybe there's some other approach that would still improve things.