Is your feature request related to a problem? Please describe.

When processing a request in a worker, failures may happen at two different levels:

• Recoverable errors in the worker module: the module recovers from the error. It may print relevant information to stderr and continue processing the request or providing an error response.
• Wasm failures: the Wasm module fails and the worker cannot recover. This may be cause by a panic in the worker, unreachable functions, or other issues. The module cannot provide a proper response and error message. wws returns the error (Wasm backtrace) to the handler.

In the first case, we're already printing any data sent to stderr from the worker. After 5207684, we're inheriting the stderr from the environment and configuring it in the WASI context. You can also configure the stderr when using wws as a library.

However, for the second case we're not printing any error and just providing a default error page:

This error exposes the Wasm backtrace. This information is very relevant for debugging on both development and production.

Describe the solution you'd like

Before sending a generic error, wws must print the Wasm backtrace in the terminal. The stderr is configurable, so the stderr_file (Option<File>) may contain a file descriptor that should be use. If it's None, you can directly call eprintln! with the proper message.

There's a different task to improve how wws manages errors (#73)

Describe alternatives you've considered

None

Additional context

• Add support for Go  #129 (comment)