Null pointers
-
Since we are now on feature freeze, only non functional changes and error corrections are accepted to our code base. My team leader assigned me to go over it and fix compilation and Klocwork warnings.
Going through the code we inherited, I'm starting to defend a mandatory "programmer's permit" (in the sense it is revocable).
Here it is just one of "violations":
public void doThings(SomeClass param) {
if(param == null) {
logger.error("*** Could not do Things for: " + param.getValue() + " ***);
}
List<ValueClass> value = map.get(param)
//... more stuff done with param ...
}
-
A former colleague of mine once requested adamantly that if he accidentally passed null to one of my functions, it needed to log where the null came from. I had difficulty explaining that my function would have no idea where the null came from, as it was the only parameter passed into it. After some back-and-forth, I ended up grabbing a stack trace if debug symbols were enabled, and logging the frame above it.
-
@joe.edwards said:
A former colleague of mine once requested adamantly that if he accidentally passed null to one of my functions, it needed to log where the null came from. I had difficulty explaining that my function would have no idea where the null came from, as it was the only parameter passed into it. After some back-and-forth, I ended up grabbing a stack trace if debug symbols were enabled, and logging the frame above it.
You should have checked for null, then logged that it came from $colleague_name.
-
@joe.edwards said:
A former colleague of mine once requested adamantly that if he accidentally passed null to one of my functions, it needed to log where the null came from. I had difficulty explaining that my function would have no idea where the null came from, as it was the only parameter passed into it. After some back-and-forth, I ended up grabbing a stack trace if debug symbols were enabled, and logging the frame above it.
Stack Traces are an important and useful pat of a log (not necessarily in the log itself, but accessible and correlatable)...IntelliTrace is even better....
-
More advanced exception handling ... wait, logging ... from the front lines (transcribed by hand, so don't hurt me terribly if I have a typo or two):
package com.example.util;
public abstract class Utilities extends Object {
public static String getMethodName() {
// declare constants
final String thisClassName = "com.example.util.Utilities";
final String thisMethodName = "getMethodName";// declare variables
String className;
int i;
String methodName;
String returnValue = null;
StackTraceElement[] stackTrace;// get a stack trace to examine
stackTrace = (new Throwable()).getStackTrace();
for (i = 0; i < stackTrace.length; ++i) {
className = stackTrace[i].getClassName();
methodName = stackTrace[i].getMethodName();
if (className.equals(thisClassName) && methodName.equals(thisMethodName)) {
break;
}
}// find the first entry that is not from the current method
for (; i < stackTrace.length; ++i) {
className = stackTrace[i].getClassName();
methodName = stackTrace[i].getMethodName();
if (! className.equals(thisClassName) && ! methodName.equals(thisMethodName)) {
// this should be the callers frame
returnValue = methodName;
break;
}
}
return (returnValue);
}}
How is it used?
package com.example.biz;
public class SomeClass {
public final static String CLASSNAME = "com.example.biz.SomeClass";
public void someMethod() {
String thisMethod = getMethodName();
String thisClass = CLASSNAME;logger.entering("Entering " + thisClass + "::" + thisMethod);
.
.
.logger.exiting("Exiting " + thisClass + "::" + thisMethod);
}}
-
zelmak,
I found the WTF. Of course, the correct way to obtain a stack trace is Thread#getStackTrace(). This will be much faster because you don't create an unnecessary exception object every time the method is called.
-
The thing is, though, that Thread.currentThread().getStackTrace() is a relatively novel addition to Java. In the old days, you had no choice but to create a new exception andgrab its stack trace.
-
@joe.edwards said:
That attitude betrays a severe lack of understanding computer programming! Though it does remind me of a colleague of mine who literally came up on punch cards since PCs didn't exist when he got his degree, to do his assignments he literally had to mail decks of punch cards and wait days for the output to be mailed back, (actually it was a wonder that he was still working at all.) This "programmer" had the strange idea that testing was a task resembling janitorial duties, and was unfit for real programmers, and should be handled by interns and the newbies. Never-mind that we didn't actually have a QA department to trow code over the wall to, and only one support tech who was represented to clients as a team of 10.A former colleague of mine once requested adamantly that if he accidentally passed null to one of my functions, it needed to log where the null came from. I had difficulty explaining that my function would have no idea where the null came from, as it was the only parameter passed into it. After some back-and-forth, I ended up grabbing a stack trace if debug symbols were enabled, and logging the frame above it.
