-
-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add README.md #2
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a few thoughts I had on a first glance
`endpoint` can be filled in order to use a specific source endpoint. | ||
Especially useful when you have multiple Internet connections and want to force a specific one. | ||
|
||
Returns an [`std::pair`](https://en.cppreference.com/w/cpp/utility/pair) containing the result code and a socket handle (also called "file descriptor"). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems odd. We are writing C++ and thus errors should be communicated by means of exceptions and not via result codes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Honestly, I've ever only used exceptions when strictly required, either by the standard library or an external one.
The "modern" way would be to use std::expected
, as it's officially introduced in C++23.
A potential alternative is Boost.Outcome
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Exceptions are still the best way of error handling, imo as they can't be ignored. They have to be handled or else the program terminates. It is unfortunate that C++ compilers don't warn you about potentially unhandled exceptions, though 🤷
Using monads is not necessarily the "modern" way of doing things. It's just another way.
However, since we don't have monads yet anyway, I would argue that exceptions are the best thing we got for the moment (certainly much better than error codes)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would argue it also depends on the way they're presented, in this library the behavior is very consistent.
On the other hand, unhandled exceptions generally trigger an automatic backtrace, which may be desiderable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even if the error codes are very consistently returned, it is just so easy to forget to check them. I've seen and also experienced this so many times and the result of that is a program that doesn't do error checking, which more often than not will lead to the program crashing somewhere down the line and then it will be much more difficult to figure out where the error came from. With exceptions, you get a crash right when and where the error appears (if you don't handle it).
9e6af21
to
c4bbe8b
Compare
0b72c62
to
84abd05
Compare
For clarity, as without the prefix another value could be expected instead. For example, the amount of bytes added in the case of Crypt::padding(). Co-authored-by: Robert Adam <[email protected]>
84abd05
to
273b691
Compare
No description provided.