Open bsupnik opened 1 month ago
@bsupnik Thanks for your feedback. Initially, the design of the Drogon framework tried to avoid using exceptions. However, as complexity increased, exceptions were eventually introduced. Therefore, using exceptions instead of directly exiting is a good choice. You are welcome to create a PR to provide a patch.
Thanks for the guidance - we'll put together a prototype and get a draft PR put together.
@bsupnik I noticed that X-Plane is a very famous flight simulation software. Would you be willing to share your project in #1878 ?
Our app (X-Plane) embeds Drogon to provide a restful API for third party add-ons. When the listening port for API requests is not available (e.g. because it is in use or some other machine-specific failure causes ::bind to fail) Trantor calls exit(), terminating the entire app.
We would like to receive an error code from the attempt to create the listener so we can alert the user that web end points are not available and continue app launch.
We can code this ourselves! I have two questions:
From a brief look at the code, it looks like we could potentially throw an exception out of the "acceptor" constructor if bind fails, and eventually catch it where the listener shared ptr is created. Is the Drogon code base meant to be exception safe, or exception free (meaning, like, don't use them)?
The alternative non-exception implementation would be to have the state of the socket be visible (through the layers of objects) such that the listener-creating code could ask (after creating the listener) "did this thing init successfully, or is it a zombie", and then throw it out if it failed.