-
-
Notifications
You must be signed in to change notification settings - Fork 156
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Reduce number of references by discarding internal previous Exception
- Loading branch information
Showing
4 changed files
with
12 additions
and
10 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
3abb49d
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.
Not really a fan of discarding the previous exception(s). Is clone an alternative to consider?
3abb49d
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.
In general I agree that previous (or "nested") exceptions make perfect sense to get a better understanding of what caused a certain exceptional situation. In this particular instance, it's my understanding that it does not add any value because all the info is already included in the
RuntimeException
returned from theSecureConnector
.In the old version, the exception message would not include the connection target at all. The new exception message now looks like
Connection to example.com:80 failed during TLS handshake: TLS error
where the nested exception would only repeat the same error messageTLS error
. This is now also consistent across this component.What do you think about this?
3abb49d
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.
It's not only the message, but also the original stack trace which gets discarded.
3abb49d
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.
@jsor Which is in fact also intentional. It does not contain any meaningful data that is not present in the exception trace that is returned from the
SecureConnector
. Note that theStreamEncryption
class is@internal
only and nothing any of our consumers should have to care about.3abb49d
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.
For the reference, the following code is expected to reject with an exception:
Take a look at the default output for this command, I honestly don't think the nested exception adds any value here (arguably it's even less clear). For the reference, here's also the full trace and the
var_dump()
output: https://gist.github.com/clue/a478dd49b4ace7ffa9828585548b0888/revisions3abb49d
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.
After discussing this with @WyriHaximus in private it seems I should have included some example error messages to begin with :-) Here's what the original exception message looked like before applying this PR:
In particular, note that while this includes a lot of low level details and is rather cryptic it does not include the basic information that this means that a connection attempt just failed and which connection was affected. This PR updates the exception to always include some higher level message and then always appends the exact underlying error message like this:
This means that this PR does in fact contain all the information that was already present previously. In addition, it makes it much clearer what the cause of this exception actually is. This applies to both the client side as in the previous example and also to the server side which now includes the remote IP so the
error
event can actually be used to diagnose issues: