Create separate UserAssert for user input errors

[jrk]

Currently, quite a few user errors result in assertions. These have been improved to be reasonably informative, but they should still be pushed off to a separate path from the implementation error asserts, specific to input program warnings and errors.

[jrk]

I'm helping set up the Python bindings for trial use in Fredo's class. Promoting user input errors to some catchable mechanism would make the user experience in Python, in particular, much better (it could show at least a Python stack trace, and would not instantly exit(1) the REPL when coding interactively).

[zvookin]

By user input errors do you mean parameters that are bad or code that
cannot be compiled? The former should be catchable via overriding
halide_error to catch the error messages. If it is called, that means an
error occured. Making all this happen in a thread safe manner is ugly, but
doable.

I'm guessing I'm missing something...

On Wed, Nov 13, 2013 at 3:08 PM, Jonathan Ragan-Kelley <
notifications@github.com> wrote:

I'm helping set up the Python bindings for trial use in Fredo's class.
Promoting user input errors to some catchable mechanism would make the user
experience in Python, in particular, much better (it could show at least a
Python stack trace, and would not instantly exit(1) the REPL when coding
interactively).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/26#issuecomment-28443579
.

[jrk]

This is a reference to our past private thread on “Halide error reporting.”

I mean user input errors at the compiler API level (constructing IR or schedules that don’t make sense, or otherwise incorrectly using the interfaces). We throw asserts with error strings not just for “oh my god, the compiler is going to blow up” invariants we maintain internally, but also for bad inputs created by user code. It would be useful if these user-gave-us-something-bad errors followed a different path from our-code-confused-itself-internally asserts, in part so that the errors can be caught rather than exiting the host program.

[jrk]

I’m glad to take an initial crack at it, if people buy that a trivial design is a worthwhile change. I’m just replacing existing asserts which relate mostly to user input with some alternate function like:

inline void Halide::Internal::user_assert(bool condition, string message)

This function could:

1. print and exit(1) (existing assert behavior)
2. raise an exception
3. do something else

I’m assuming (1) by default for now, with either #ifdefs or runtime flags to change to (2).

Is this worthwhile, or would people rather continue waiting for a full rethink of the compiler error handling stack as discussed off-list in July?

[abadams]

I buy that the trivial design is a worthwhile change.

On Wed, Nov 13, 2013 at 3:34 PM, Jonathan Ragan-Kelley <
notifications@github.com> wrote:

I’m glad to take an initial crack at it, if people buy that a trivial
design is a worthwhile change. I’m just replacing existing asserts which
relate mostly to user input with some alternate function like:

inline void Halide::Internal::user_assert(bool condition, string message)

This function could:

1. print and exit(1) (existing assert behavior)
2. raise an exception
3. do something else

I’m assuming (1) by default for now, with either #ifdefs or runtime flags
to change to (2).

Is this worthwhile, or would people rather continue waiting for a full
rethink of the compiler error handling stack as discussed off-list in July?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/26#issuecomment-28445379
.

[abadams]

A prototype of a more extensive rework of error conditions is in the introspection branch. It does a superset of the above.

[abadams]

merged into trunk in 525176e

[jrk]

Much like.