Debugging Emscripten's Module is relatively straightforward. Emscripten's error messages are well formed and descriptive, so you'll usually discover what's causing the issue right away. You can view these messages in your browser's development tools console.

If you specified a .html output when running the emcc command, some debugging code will already be built in (Module.print and Module.printErr). Within the HTML file, the loading code sets the window.onerror event to call the Module.printErr event, so you can see details about the error that occurred when loading.

One common error you may encounter is calling the wrong function name. If you're using Emscripten's Promise-like API, you can print out the available functions by running the following code in your browser's console:

console.log(Module().asm);

The following screenshot shows the output for the js-with-glue.js example we used in the Calling JavaScript functions from C/C++ section of this chapter:

Your functions, as well as some functions that Emscripten generates, will be prefixed with a _. The advantage of writing code that gets compiled is that the compiler will catch most errors up front. Given the extensive tooling available for languages such as C and C++, you should be able to understand and address these errors quickly.

If you're not using any glue code and instantiating a Wasm file using WebAssembly's JavaScript and Web APIs, debugging can get a little more complex. As previously stated, you have the advantage of catching most errors at compile time in your C or C++ code. Just as with Emscripten, the error messages printed out in your browser's development tools console provide a stack trace and a relatively clear description of the issue. However, logging to the console may become cumbersome and difficult to manage if you're troubleshooting a particularly difficult bug. Fortunately, you can use source maps to improve your debugging capabilities.