On some platforms errors are silently swallowed when exceptions are enabled

[abadams]

Uncaught exceptions aren't guaranteed to print, which means by default we don't have any kind of error reporting at all on windows when you compile Halide with exceptions. Things that are user errors are present as crashes. GenGen has a top-level exception handler, so generators should be fine. However, JIT usage is very unfriendly. I'm not sure what to do about this.

[alexreinking]

Proposal: programs using Halide in JIT mode should expect to have to catch Halide::Error, which could be any of Halide::CompileError, Halide::RuntimeError, or Halide::InternalError. We should make Halide::Error pure virtual so exceptions can be caught generically, but so we can't throw any uncategorized exceptions. We currently only throw Error in four places across PyError.cpp and PyStubImpl.cpp, so this shouldn't be hard to change.

Then, "large" functions like compile_jit should catch and rethrow Halide::InternalError while also printing a message on a non-default debug() level.

[alexreinking]

I am still not sure what the right solution to this is. It seems this is just "one of those Windows things". We got a report on Gitter from @oelgendy

Hi folks,
Thanks for adding all auto-schedules to Halide 10
I used to do autoscheduling for Halide pipelines in Halide 8 by using the following code

Pipeline P(FuncName);
Halide::Target target = Halide::get_host_target();
MachineParams param(MachineParams::generic());
AutoSchedulerResults Schedule = P.auto_schedule(target, param);
cout << "schedule_source: \n" << Schedule.schedule_source << endl;

However, this code crashes the program when I use Halide 10, What am I missing here? There were no error messages

It worked by loading the autoscheduler plugin before calling the auto_schedule function

Halide::load_plugin("autoschedule_adams2019.dll");

...
It gave me this error message:
Unhandled exception at 0x00007FF9F0503B29 in Halide_AOT.exe: Microsoft C++ exception: Halide::CompileError at memory location 0x000000C5F35FEEA8.
I am using VS 2019

I googled a bit more and found these SO posts lamenting the state of things, but there is no fix:

https://stackoverflow.com/questions/13498348/where-can-i-see-the-what-message-from-an-unhandled-stdexception-in-visual-st
https://stackoverflow.com/questions/43231974/can-i-view-an-unhandled-exception-in-the-visual-studio-2017-debugger/46348413

In JIT mode, we don't control the user's exception policy. It's up to them, I think, to catch exceptions and print the e.what() message.

[oelgendy]

Thanks @alexreinking , this try-catch block works perfectly on VS 2019

try {
  ...
} catch (std::runtime_error &err) {
  std::cerr << "Unhandled exception: " << err.what() << "\n";
  return 1;
}

[alexreinking]

@abadams - Maybe the right solution is to print the error message on Windows when exceptions are enabled, and then still throw anyway?

[abadams]

Perhaps controlled by a #define so it can be silenced. E.g. HALIDE_PRINT_AND_THROW_ON_ERROR=1/0?

We'd default to printing

[alexreinking]

A #define doesn't help someone if they get a binary release... maybe we use debug(1) instead?

[abadams]

debug is no good because it's off by default. We need something on by default. My proposal with the #define was that defining it to be 0 would do something like create a static constructor in Halide.h that sets a global flag inside Error.cpp.

We could also just add a global function to Error.cpp/h that silences it.