Thursday, October 26, 2006
Tuesday, September 19, 2006
Wednesday, July 26, 2006
Getting rid of Null Pointers
NullPointerException or Null Object Reference errors are so common in any Object Oriented programming languages, be it ubiquitous Java or C#, that programmers have accepted it as a 'feature'. This happens when a reference (an object handle) pointing to ‘no-where’ is called in to service a request during the execution of a program. In the traditional languages like C, it would be a memory location without any serviceable address assigned. What is worse is that, such creepy things stay unnoticed while building the executable and surface only when someone uses the ‘shipped’ program. This not only leads to the annoyance and frustration to the consumer of the program, but also reveals the ‘ability’ of the software developer to him/her. Just look at so many jokes floating around involving the software developer community.
Yesterday stayed awake till late in the night. I was trying to book a ticket at a well-known website and this is what I encountered on the screen:
java.lang.NullPointerException: null at org.apache.struts.taglib.template.InsertTag.doEndTag(InsertTag.java:133)
at booking._0002fbooking_0002fbookTicket_0002ejspbookTicket_jsp_
1._jspService
(_0002fbooking_0002fbookTicket_0002ejspbookTicket_jsp_1.java:485) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:126) at
javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.jasper.runtime.JspServlet$JspServletWrapper.service(JspServlet.
java:174) at org.apache.jasper.runtime.JspServlet.serviceJspFile(JspServlet.java:268)
at org.apache.jasper.runtime.JspServlet.service(JspServlet.java:381) at
javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at com.broadvision.servlet.ServletContainer.service(ServletContainer.java:404
) at com.broadvision.servlet.BVRequestDispatcher.forward(BVRequestDispatcher.ja
va:133) at …
While, clearly above is a testimony to a poor QA activity, but, the responsibility of the coder is no less severe either. Actually, it perhaps mirrors a poor coding practice followed by him/her which went unnoticed throughout the entire SDLC.
There is very little that a language compiler can do to check and alert the coder if he/she is leaving a dangling reference attached to 'nothing' before the code actually runs and the OS detects that the program has tried to reach a location that is either out of bounds for the current code or it is not present in the universe (mem address space) at all. Therefore, all null pointers show up only at the first usage of a handle (reference or pointer) that points to a NULL location.
If surfacing unsolicited was not enough, such ‘runtime’ exceptions generally carry useless information along to be of any help during debugging, unless the coder has implemented a meticulous audit/tracing plan. Try to decipher what went wrong in the above exception message? Here the coder at least was fortunate to have a dorky build engineer who allowed to ship the software with debug information on (look at those source code line numbers) otherwise, stack trace would have been dumber with no evidence of what went wrong and where… I mean you would not find any line numbers and if the code was subjected to massive compiler optimization then it would loose every bit of its identity due to the mangling of information and sometimes further obfuscated by dynamic compilation by JITC.
So, as they say, prevention is the best cure. Do not write code that can suffer from such an ailment and writing code as given below is suicidal. In the following example I am trying to fetch some ‘textual’ information from a Database (DB).
String txtData = getCollectionFromDB().getSomeDataForNamedKey().getValue().trim()
This looks smart (?) But, IMHO usages like this is the single biggest source of null pointers and other hypodermic bugs.
Yes, in our DB, values can be "NULL" or there may not be a matching row to fetch. Practice of in lining many calls as above is a great source of null pointer exception especially, if the data is coming from outside your code 'boundary'. Here you have absolutely no control over what is coming to you. In the above snippet, all the method calls preceding the dot (.) operator could give you a null reference leading to the exception. E.g. trim() would fail on a null value returned by getValue(); getValue() would fail on a null Object fetched by getSomeDataForNamedKey() and so on.
Why would you write code like this? This programming practice does not save anything except may be some of your typing time and finger ache! Instead of being stingy on words and lines as above, try to break calls into individual ‘statement’ and combine such statements into a code block (example shown below). This not only yields a more robust code but, also makes code easier to comprehend. Whats more, the debugger tools will also report proper line numbers happily.
Map nameValuePairMap = getCollectionFromDB();
if( isNull(nameValuePairMap) )
{
//do Blah Blah
}
else
{
NameValuePair someNameValue = nameValuePairMap.GetSomeDataForKey();
// Do Null check
...
String dataValue = someNameValue.GetValue();
if( isNull(dataValue) )
{
txtData ="";
}
else
{
txtData = dataValue.trim();
}
...
}
Follow this and & > 80% of your programming bugs (especially Null pointers) would disappear.
Ask me how do I know that :-)
Yesterday stayed awake till late in the night. I was trying to book a ticket at a well-known website and this is what I encountered on the screen:
java.lang.NullPointerException: null at org.apache.struts.taglib.template.InsertTag.doEndTag(InsertTag.java:133)
at booking._0002fbooking_0002fbookTicket_0002ejspbookTicket_jsp_
1._jspService
(_0002fbooking_0002fbookTicket_0002ejspbookTicket_jsp_1.java:485) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:126) at
javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.jasper.runtime.JspServlet$JspServletWrapper.service(JspServlet.
java:174) at org.apache.jasper.runtime.JspServlet.serviceJspFile(JspServlet.java:268)
at org.apache.jasper.runtime.JspServlet.service(JspServlet.java:381) at
javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at com.broadvision.servlet.ServletContainer.service(ServletContainer.java:404
) at com.broadvision.servlet.BVRequestDispatcher.forward(BVRequestDispatcher.ja
va:133) at …
While, clearly above is a testimony to a poor QA activity, but, the responsibility of the coder is no less severe either. Actually, it perhaps mirrors a poor coding practice followed by him/her which went unnoticed throughout the entire SDLC.
There is very little that a language compiler can do to check and alert the coder if he/she is leaving a dangling reference attached to 'nothing' before the code actually runs and the OS detects that the program has tried to reach a location that is either out of bounds for the current code or it is not present in the universe (mem address space) at all. Therefore, all null pointers show up only at the first usage of a handle (reference or pointer) that points to a NULL location.
If surfacing unsolicited was not enough, such ‘runtime’ exceptions generally carry useless information along to be of any help during debugging, unless the coder has implemented a meticulous audit/tracing plan. Try to decipher what went wrong in the above exception message? Here the coder at least was fortunate to have a dorky build engineer who allowed to ship the software with debug information on (look at those source code line numbers) otherwise, stack trace would have been dumber with no evidence of what went wrong and where… I mean you would not find any line numbers and if the code was subjected to massive compiler optimization then it would loose every bit of its identity due to the mangling of information and sometimes further obfuscated by dynamic compilation by JITC.
So, as they say, prevention is the best cure. Do not write code that can suffer from such an ailment and writing code as given below is suicidal. In the following example I am trying to fetch some ‘textual’ information from a Database (DB).
String txtData = getCollectionFromDB().getSomeDataForNamedKey().getValue().trim()
This looks smart (?) But, IMHO usages like this is the single biggest source of null pointers and other hypodermic bugs.
Yes, in our DB, values can be "NULL" or there may not be a matching row to fetch. Practice of in lining many calls as above is a great source of null pointer exception especially, if the data is coming from outside your code 'boundary'. Here you have absolutely no control over what is coming to you. In the above snippet, all the method calls preceding the dot (.) operator could give you a null reference leading to the exception. E.g. trim() would fail on a null value returned by getValue(); getValue() would fail on a null Object fetched by getSomeDataForNamedKey() and so on.
Why would you write code like this? This programming practice does not save anything except may be some of your typing time and finger ache! Instead of being stingy on words and lines as above, try to break calls into individual ‘statement’ and combine such statements into a code block (example shown below). This not only yields a more robust code but, also makes code easier to comprehend. Whats more, the debugger tools will also report proper line numbers happily.
Map nameValuePairMap = getCollectionFromDB();
if( isNull(nameValuePairMap) )
{
//do Blah Blah
}
else
{
NameValuePair someNameValue = nameValuePairMap.GetSomeDataForKey();
// Do Null check
...
String dataValue = someNameValue.GetValue();
if( isNull(dataValue) )
{
txtData ="";
}
else
{
txtData = dataValue.trim();
}
...
}
Follow this and & > 80% of your programming bugs (especially Null pointers) would disappear.
Ask me how do I know that :-)
Saturday, July 08, 2006
Saturday, June 17, 2006
Wednesday, June 14, 2006
Abstraction and Encapsulation
These days I conduct a lot of job interviews to fill up few vacant positions for developers in our group. Typical profiles that I get read something like:
Yesterday, I interviewed one such candidate. As expected, he too had a well endowed resume not different from the above sample, though. I am reticent even during interviews. Hence, he was quizzed mostly by my colleague. I just had one question at the end:
I have been asking this question to every 5+ years I see. However, rarely I get a pleasing answer. No wonder we still remain a land of ‘Cyber Coolies’!
For the benefit of next candidate I have to interview, here are some links to look at:
http://www.itmweb.com/essay550.htm
http://www.javaworld.com/javaworld/jw-05-2001/jw-0518-encapsulation.html
http://www.artima.com/intv/abstreffi.html
http://forum.java.sun.com/thread.jspa?threadID=280797&messageID=1092364
It is important to learn how to abstract what you know and encapsulate what you don't before you appear for a job interview !
:-)
<<S. RamaLinga Reddy>>The first page is normally crammed with such accomplishments and aspirations. One Reddy I saw had included this too “H/W: Pentium-III, 633MHz, 128 MB RAM, 8.3 GB SCSI- II HDD, 32x CDROM, 1.44 (3.5 in) FDD, PCI BUS Architecture”. Next tens of pages lists the projects he has worked like: “Web Based Employee Attendance Management System”, “Employee Data Management System”, “Ticket Reservation Systems” and so on.
Hyderabad
BCA, MCA, PGDST, e-DAST, NSCT,NIIT…(yes IT qualifications in India look like degrees of a medical practitioner- the more the better)
5+ years in IT
Expert in C#/.NET, ASP.Net, VB.Net,C, C++, Java,
Knowledge of COM, DCOM, COM+, MTS, SQL Server, IIS, Windows, Unix (?), OOP, Design Patterns…
Responsible for FSD, LLD, HLD, CUT…
Wannabe S/W Architect
Yesterday, I interviewed one such candidate. As expected, he too had a well endowed resume not different from the above sample, though. I am reticent even during interviews. Hence, he was quizzed mostly by my colleague. I just had one question at the end:
What is the difference between Abstraction and Encapsulation?End of interview!
Answer: Both are actually same…umm...like Encapsulation...is Encapsulating things in a class and...umm ... Abstraction is Abstracting somethings inside a class...umm...blah blah blah
I have been asking this question to every 5+ years I see. However, rarely I get a pleasing answer. No wonder we still remain a land of ‘Cyber Coolies’!
For the benefit of next candidate I have to interview, here are some links to look at:
http://www.itmweb.com/essay550.htm
http://www.javaworld.com/javaworld/jw-05-2001/jw-0518-encapsulation.html
http://www.artima.com/intv/abstreffi.html
http://forum.java.sun.com/thread.jspa?threadID=280797&messageID=1092364
It is important to learn how to abstract what you know and encapsulate what you don't before you appear for a job interview !
:-)
Thursday, May 11, 2006
Tuesday, May 02, 2006
Thursday, April 13, 2006
Wow - What a Ride!
Life should NOT be a journey to the grave
with the intention of arriving safely
in an attractive and well preserved body,
but rather to skid in broadways,
Haywards in one hand - Goldflake in the other,
body thoroughly used up, totally worn out, and screaming
with the intention of arriving safely
in an attractive and well preserved body,
but rather to skid in broadways,
Haywards in one hand - Goldflake in the other,
body thoroughly used up, totally worn out, and screaming
Don't know who said this- but very well said indeed!
Monday, March 27, 2006
On Sale
Jan 1998 black Yamaha RXZ, Pune registered
Done ~48000 kms
Single handedly driven,
Excellent condition, Looks much younger,
Fed on Speed, Premium and Power
New battery,
New front tyre,
Semi-new rear tyre (done 20,000 kms)
Comprehensive insurance paid upto Feb, 2007
PUC valid up to august, 2006
Expected price 16,000/- (negotiable)
Reason for sale: going for a Royal Enfield Bullet
Contact: hi2bj AT sify DOT com
She has served me very well for the past eight years…now is the time to bid her adieu :-(
Done ~48000 kms
Single handedly driven,
Excellent condition, Looks much younger,
Fed on Speed, Premium and Power
New battery,
New front tyre,
Semi-new rear tyre (done 20,000 kms)
Comprehensive insurance paid upto Feb, 2007
PUC valid up to august, 2006
Expected price 16,000/- (negotiable)
Reason for sale: going for a Royal Enfield Bullet
Contact: hi2bj AT sify DOT com
She has served me very well for the past eight years…now is the time to bid her adieu :-(
Wednesday, March 15, 2006
Wednesday, March 08, 2006
What's new?
Nothing...! Just happened to click these snaps of Diya on a Sunday couple of weeks back.
Emu and quails
Drive down to Tony Da Dhaba near Kamshet on Pune Mumbai road (NH-4) to see these birds live
Thursday, March 02, 2006
Loosing patience!
I have not received my renewed passport yet and it does not look to be happening in a near future either. For past three weeks, I see the same poster: "It is to regret that due to unavoidable circumstances the despatch of Passport has been delayed and will now be despatched in a week's time". Mails to rpo DOT pune AT mea DOT gov DOT in are not answered !!
Anyone (other than me) stuck at the same damn status?
:-(
Anyone (other than me) stuck at the same damn status?
:-(
Friday, February 24, 2006
Kabhi Socha Thaa?
Indian Railways launches loyalty programme called SOFT (Scheme for Frequent Travellers)!!
Thursday, February 02, 2006
Trip to Ganpatipule
26th of January was a Thursday. We grabbed this opportunity to extend the weekend by bunking next day and set out for a family outing to Ganpatipule. This is a tiny hamlet in southern Konkan known for its shiny beach and a four centuries old temple of Lord Ganesha. People visit here with different agendas. Some of them come here just to pay respect and pray to the Lord; some drop in to enjoy the sun kissed beach and laze around while others simply leave hustles and bustles of city life behind to enjoy the splendid drive down the NH17 meandering through scenic Konkan countryside. I had all of these motives in different proportions. We reached here via Chandni Chowk-> Mulshi-> Kolad-> NH17-> Chiplun -> Sangameshwar. Beyond Paud, SH60 is in a very good shape with fresh asphalt. Nothing to complain about NH17 except few miles of wrinkled tarmac between Mahad and Kashedi ghat. We made it by 6PM to MTDC resort and had an awesome view of the sun setting 
into the Arabian sea. Evening went by hogging kebabs and beer. Pleasure was upped as Bipul and his better half paid for them (they were celebrating second wedding anniversary). Diya and Shirin preferred to sleep through the feast.Three days of delectable indolence passed like a trice and now back to the stock humdrum of urban life!
More pics from the trip.
Tuesday, January 31, 2006
Patience Pays
Once again I checked the status today. But, unlike last time now it says:
Hope my trust in the system is not betrayed.
"Police Report is clear and the passport is expected to be despatched by 18-02-2006 Subject to all documents being in order."I have not paid any bribe to get it cleared. Which makes me believe that our government agencies can really work. What you need is an 'honest' patience to wait (I have waited for over ten weeks now) for the results to happen naturally. Most often it is only us, who try to catalyze the process by greasing with bribes, in order to 'accelerate' results.
Hope my trust in the system is not betrayed.
Saturday, January 28, 2006
Time
"...And you run and you run to catch up with the sun, but it's
sinking
And racing around to come up behind you again
The sun is the
same in the relative way, but you're older..."
Sunset at Ganpatipule near Ratnagiri, Konkan Coast
Subscribe to:
Posts (Atom)