Skip to content

Rework subtypes populating code algorithm #7010

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.

Sign up for GitHub

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

Closed
wants to merge 1 commit into from
Closed

Rework subtypes populating code algorithm #7010

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 6 additions & 6 deletions spring-boot/src/main/java/org/springframework/boot/web/support/ErrorPageFilter.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -223,12 +223,12 @@ private String getErrorPath(Class<?> type) {
if (this.subtypes.containsKey(type)) {
return this.exceptions.get(this.subtypes.get(type));
}
Class<?> subtype = type;
while (subtype != Object.class) {
subtype = subtype.getSuperclass();
if (this.exceptions.containsKey(subtype)) {
this.subtypes.put(subtype, type);
return this.exceptions.get(subtype);
Class<?> supertype = type;
while (supertype != Object.class) {
supertype = supertype.getSuperclass();
if (this.exceptions.containsKey(supertype)) {
this.subtypes.put(type, supertype);
Copy link
Member

@wilkinsona wilkinsona Sep 27, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like more than a typo correction. You've swapped the key and value in this call to put. Was that intentional?

Copy link
Author

@ghost ghost Sep 27, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi! Yes It was intentional as I've mentioned in the first comment to this PR. I also changed variable name from subtype to supertype because I suspect it was the reason for initial mistake (swapped put arguments) since it was suggesting different relation between arguments.

Copy link
Member

@wilkinsona wilkinsona Sep 27, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then shouldn't the containsKey check have been updated too?

Copy link
Author

@ghost ghost Sep 27, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think so. The way I'm reading this code, we only want to save this particular supertype if we have an explicit exception mapping for it, if not, we should continue upwards till we find the one or there is no more types to check.

Copy link
Member

@wilkinsona wilkinsona Sep 27, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, yes. It's a different map. Well, if nothing else, this discussion has shown that the code's confusing to me at least.

I also think that the PR has shown that we're missing some tests. You've changed the behaviour, but haven't had to change any tests. That's bad. I'd like to see some tests around this before we change anything.

Copy link
Author

@ghost ghost Sep 27, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This class has a nice battery of tests, but what's more important I haven't changed the contract (behaviour visible from the outside is still the same), but rather fixed an internal optimization. I can't see how I may test this particular internal implementation detail without exposing it, which I think would be a bad thing. If you could shed some light on the way you'd wish such test to be implemented, I'd be most grateful.

Copy link
Member

@wilkinsona wilkinsona Sep 28, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to be clear, I was saying that the current code and tests are bad, not your PR.

Given that it would appear that the optimisation is faulty in its current state, and no one has raised it as a performance problem, I'm very tempted to remove it and simplify the code. If the optimisation is worth having then it's worth testing. To do that, the filter will need to be refactored. I would create a separate package-private class that's sole responsibility is mapping from a status or exception to an error path and implement it in such a way that it can be spied on or whatever to verify that the optimisation is working as intended.

Copy link
Author

@ghost ghost Sep 28, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry if I seemed offensive, I didn't mean to. I was thinking as well that if nobody noticed it wasn't working, than maybe it's redundant and it'd be better to just remove this piece to reduce complexity. But since I'm no expert on performance optimizations, please decide if you want to keep it and I should refactor & test it, or you wish it simply removed.

return this.exceptions.get(supertype);
}
}
return this.global;
Expand Down