4 ms·
Varargs methods in Java was one that bit me with an overload in the past (my tale of is told in more detail at http://the-whiteboard.github.io/java/debugging/wa
by shagie 3y ago
Varargs methods in Java was one that bit me with an overload in the past (my tale of is told in more detail at http://the-whiteboard.github.io/java/debugging/warstory/2016/07/27/dont-overload-varargs.html http://the-whiteboard.github.io/java/debugging/warstory/2016... )
The issue was that there was a framework class with the method signature of execute(Object ... inParams). The class had overloaded the method signature to be execute(String foo, String bar). If you called it with two args, it got the overloaded call and there were a half dozen calls to this method.
At some point, someone added another argument to this so that it was execute(String foo, String bar, String qux) and updated the half dozen less one methods to use the third parameter.
However, the two args call in some other code still compiled correctly because it now went back to calling execute(Object ... inParams). Though, the parameters were completely wrong for that call structure and the application suddenly sprouted runtime errors.
- int_19h 3y agoThis kind of thing is exactly why in C++, when a derived class declares a method, it doesn't just overload any methods with the same name inherited from the bases, but hides them. If you actually want overloading across the hierarchy, the derived class needs to explicitly opt into it by "using" the base methods it needs.
- tpoacher 3y agoIn fairness, it was pretty reckless to just "update" the existing method without providing a dummy "throw an informative error if anything attempts to call the old method" fallback method
- shagie 3y agoThere were all sorts of "wrong" with that attempted refactoring that goes back to the original "subclass the StoredProcedure class and overload the execute(Object ...) method rather than creating a new one... and name it callProc (for example). Note that the execute methods ( https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/jdbc/object/StoredProcedure.html https://docs.spring.io/spring-framework/docs/current/javadoc... ) all are suggested for subclass invocation rather than external. I'd have to spin up a test to verify, but I believe that if Spring had made it a protected method so that execute could only be called by a subclass rather than public where it can be called from other methods in other classes it would have mitigated the issue that allowed for the original developer to overload it. That would have made it so when the arguments changed it now was a compile error since the execute(Object...) form of the call would only have been accessible from the subclass.