How to test exceptions

[polidobj]

I'm thinking of writing test classes in Fusion to test my code. But how could we test that a function that throws exceptions throws one when it is expected to throw? The first way that comes to mind is being able to catch a thrown exception.

[pfusik]

I will add try/catch. This should be rather straightforward in most target languages, except for C, OpenCL (which don't have exceptions) and JavaScript/TypeScript (which cannot catch by type).

For now, you can test in one of the target languages, e.g. call Fusion code from C# and catch the exception in C# (either directly or with one of the unit test frameworks).

[danon]

You can catch by JavaScript type (not by TypeScript type, because they're lost in runtime).

class Foo extends Error {}
class Bar extends Error {}

try {
  code();
} catch (error) {
  if (error instanceof Foo) {

  } else if (instanceof Bar) {

  } else {
    throw error;
  }
}

[msteinbeck]

Regarding exception handling in C, what is your opinion on transpiling exceptions to setjmp/longjmp? Functions that declare throws Exception could specify an additional argument, e.g., jmp_buf fut_jmp_buf, which is then used by throw. The exception message could be stored in a global (thread-local) variable. Typically, when using setjmp/longjmp, memory management is tricky because dynamically allocated memory is not released automatically. However, Fusion seems to already handle dynamically allocated memory when handling exceptions. This way, a function calling another function that declares throws Exception could create an "intermediate" jmp_buf instance that is passed to the called function and if an exception is thrown, clean up locally allocated memory before jumping to the caller via fut_jmp_buf. It is even imaginable to track the stack trace this way.

[pfusik]

Thanks for your comment!

I'm not happy with how the exceptions are currently transpiled to C:

• many return types (int, bool, enum, nullable references) are not allowed for functions throwing exceptions
• the exception type and the message are lost

I'm not a big fan of setjmp/longjmp - it's awkward to use. Especially the memory management on the user side with such a non-trivial control flow.

I consider:

• thread-local variables
• returning structures that contain both the result type and the exception info
• returning the exception as the return value while returning the actual value via a pointer parameter
• setting up exception handler functions (via a parameter or thread-local variable) - this user-provided handler could do a longjmp if the user opts to

[danon]

@pfusik You don't have to introduce exceptions to the fusion language, because not all target languages support it well. I think it would be way better to introduce a convention from go-language, which just returns a tuple informing about an error, something like that:

function tryOrFail() {
  if (success) {
    return [true, 12];
  }
  return [false, null];
}

Yes, each caller needs to read it and pass it along, but it's already doable in all of the target. There can be supporting methods that make using such things easier to use.

Exceptions are essentially control flow elements that cut across call stack, and it's hard to streamline across all targets.