-
Notifications
You must be signed in to change notification settings - Fork 96
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
Exceptions seem to lack information #56
Comments
You are right, I will address the issue in the future. |
In this sense I wonder what's the design decision behind catching asio (ssl) errors and rethrow them as mailio errors? Because asio is such a vital core part of the communication layer, we definitely need the underlying communication error. |
It was meant to move them away as low level errors. But from your and some other comments, I see there is a need to trace these errors as well the errors received from servers. Thus, I plan to extend the mailio exceptions with these additional data. In this version I am dealing with the various encoding issues, so probably I'll let the error handling for the next version. |
Hello.
Exceptions in
mailio
often don't seem to be very informative, e.g.:throw message_error("Parsing failure of the message ID.");
or
throw pop3_error("Parser failure.");
which unfortunately don't say much about the value that caused this exception or the reason.
Perhaps you could somehow extend exception interfaces to allow saving and retrieving additional info which could be the exact value that failed to parse or at least some context that could help to track down the issue if the exact value isn't available at the time when exception is thrown?
It probably would be better if there was another parameter for
message_error
(and the likes) constructor, likeconst std::string& token
orconst std::string& context
which could also be retrieved in exception handler using a corresponding method, likeget_error_token()
orget_context()
.This way it doesn't break anything for anyone because all who wants to have nice and clean human-readable messages will still get those with no edits required on their side. It would require editing of the library code though.
An example implementation:
Also, it would probably be better to store both the invalid token AND the context in which it appeared because there are cases when few
case
blocks ofswitch
produce exceptions with the same message but for different states of the parser, or the cases like this one when you throwpop3_error
and we lose the original exception reason:mailio/src/pop3.cpp
Lines 127 to 134 in f82f7e8
In such cases it probably could be better to save
ex.what()
as the exception context similarly to what was described above.The text was updated successfully, but these errors were encountered: