Describe the bug
Currently the server Server::build_listener implementations (both unix and not(unix)) panics when the binding fail for any reason.
To Reproduce
Steps to reproduce the behavior:
Launch any app using trillium with a given host/port config that is not available on the machine
Panics occur and app stop
Expected behavior
To not crash but either returning immediately and/or providing a way to programmatically handle this case (like a new entry in Config like with_binding_failure_handler or other way to not break the API by changing the run/run_async return type.
At least a precision in the doc that run/run_async may panic in some cases would be nice.
Output
thread 'main' panicked at /home/quentin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/trillium-server-common-0.4.7/src/server.rs:64:68:
called `Result::unwrap()` on an `Err` value: Os { code: 98, kind: AddrInUse, message: "Address already in use" }
Additional context
I'm using Trillium for inner implementation of HTTP server in Mélodium language, for which crashing because of binding failure is not a admissible behavior.
Circumvent
Actually the way to prevent this is to create the binding by ourselves and then give it to the config.
This will make the Server::build_listener implementation using the given (already bound) listener instead of doing it with possible panics.
Describe the bug Currently the server
Server::build_listener
implementations (bothunix
andnot(unix)
) panics when the binding fail for any reason.To Reproduce Steps to reproduce the behavior:
Expected behavior To not crash but either returning immediately and/or providing a way to programmatically handle this case (like a new entry in
Config
likewith_binding_failure_handler
or other way to not break the API by changing therun
/run_async
return type.At least a precision in the doc that
run
/run_async
may panic in some cases would be nice.Output
Additional context I'm using Trillium for inner implementation of HTTP server in Mélodium language, for which crashing because of binding failure is not a admissible behavior.
Circumvent Actually the way to prevent this is to create the binding by ourselves and then give it to the config. This will make the
Server::build_listener
implementation using the given (already bound) listener instead of doing it with possible panics.Before:
After: