Join devRant
Do all the things like
				++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
				Sign Up
			Pipeless API
 
				From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
				Learn More
			Search - "nullreferenceexception"
		
- 
				    					
					
					We receive an email from Splunk when errors go above a certain threshold, and a particular service has been especially problematic this week (throwing hundreds of exceptions). Email response from the team mgr responsible for the service.
 
 "We are working to address these errors. We don’t currently have a way to prevent a user who’s account is locked from logging into the service and performing work."
 
 The exception? NullReferenceException: Object reference not set to an instance of an object.
 
 The code? (paraphrasing)
 
 var user = GetUser(request.Login);
 if (user.CanPerformWork) ...
 
 <facepalm>
 
 I'm doing my best not to reply .."Really? No way? You do realize we can read code, right?"4
- 
				    					
					
					Okay, let's get this fight rolling: here's a typical .net error message:
 
 An error occurred. (An error occurred.) The type of this error was: An error occurred. Additionally, an error occurred while the error was occurring. The type of this error was: An error occurred.
 
 Additional information: NullReferenceException at line... haha not really fucko, an error occurred.2
- 
				    					
					
					This story starts with a call from the 1st line support that users were getting intermittent-production-only error in one of the key application my team were working on.
 
 The problem was that the application was behind the hardened environment that we had no access to.
 
 The only thing we could do is enable logging which in itself took a whole week to get approved. And the result the Developers favourite - NullReferenceException in one of the biggest methods, I've ever seen in my whole career. Needless to say, that was not very helpful and we were no closer to the solution.
 
 What. A. Pain.
 
 Frustrated with the issue and with business breathing down my neck I started slicing this Monster of a method into smaller and smaller chunks. Even if some action was just a one-liner that would not stop me to create a method. At one point I could no longer care for method names resorting to such classics like Method1, FooBar123 and DoStuff.
 But. It. Worked.
 
 After the next deployment logs were showing the same NullReferenceException but now the stack trace pointed me to some Method13.
 The resulting stack trace finally allowed to pinpoint the issue. The fix then was just a simple null check.
 
 While Dev team who did not appreciate my creative method naming it was obvious to everyone that even that was better than one big blob of code.
 
 It might seem silly to separate the most obvious one-liners into their own methods and sometimes even whole classes but not living through that experience alone is worth it for me.
 
 Did you ever found yourself in a situation where you wished your stack trace was just a little bit more in-depth? Tell me in the comments ^_^
 
 So now go and look at your code and see if you can pepper it with smaller methods so that you stack traces can pave your way to your debugging success.
 
 Originally posted on amoenus.dev/no-method-too-small-or-amoenus-dev 3 3









