Create separate UserAssert for user input errors about halide HOT 8 CLOSED

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).

from halide.

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 <
[email protected]> 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
.

from halide.

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.

from halide.

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?

from halide.

I buy that the trivial design is a worthwhile change.

On Wed, Nov 13, 2013 at 3:34 PM, Jonathan Ragan-Kelley <
[email protected]> 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
.

from halide.

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

from halide.

merged into trunk in 525176e

from halide.

Much like.

from halide.