Skip to content
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

Be defensive when calling toString() on object in MatchError.getMessage #7912

Closed
scabug opened this issue Oct 14, 2013 · 2 comments
Closed

Be defensive when calling toString() on object in MatchError.getMessage #7912

scabug opened this issue Oct 14, 2013 · 2 comments
Assignees
Milestone

Comments

@scabug
Copy link

@scabug scabug commented Oct 14, 2013

If Throwable.getMessage throws an exception, no matter whose fault it is, this will make debugging an application that throws such an exception very difficult, because the original exception will be lost when a logger tries to log the exception message. Scalas MatchError.getMessage method will throw an exception if the object that failed to match throws an exception from its toString method. That object of course shouldn't throw an exception from its toString method, but if that object is from a third party library and you just want to debug your application, knowing who to blame is little consolation.

MatchError.getMessage should therefore be defensive when invoking toString on the object, catching any exceptions caught, and if such an exception was caught, displaying a message like this instead:

"an instance of class " + obj.getClass.getName

It could probably also add information about exception caught, eg saying "Additionally, an exception was thrown when the toString() method was invoked: ...", but this is not strictly necessary.

@scabug
Copy link
Author

@scabug scabug commented Oct 14, 2013

Imported From: https://issues.scala-lang.org/browse/SI-7912?orig=1
Reporter: @jroper
Affected Versions: 2.10.3

Loading

@scabug
Copy link
Author

@scabug scabug commented Dec 9, 2013

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants