Epiphany with Errors
I never looked at error statements in the first place..!
Yes, that haunting red-coloured text: Usually responsible for scaring the souls of mere mortals. This little text observed whenever programmers try to compile more than two new lines of code is omnipresent.
So handling error statements, what’s the big deal?
Well, they are a no-brainer for some of us just another trivial detail to be considered and learned. As I juggle hard between finding a job, grinding LeetCode and building cool projects. Here, I share my experience and thoughts on error statements.
I was sipping coffee as I watched this python tutorial on YouTube related to Classes and Objects and took a deep dive into the error statement below:
x = 5
print(x.upper()) AttributeError: ’int’ object has no attribute ‘upper’
I remember while watching the video I heard, variable x is an object of the class ‘int’ that does not have an attribute named upper() in it.
Later, when I saw the error this is how I read it to myself:
upper() method as x contains an integer and the upper() method only works with ‘string’This is absolutely fine but an additional way of reframing the same could be:
upper() attribute only applies to the objects created with the ‘str’ object.
That there, a simple reframe could have solved half of my worries and fears related to error handling but let’s just discuss why I couldn’t do it initially.
Firstly, instead of reading the error statement properly and understanding what it could mean. I would skim over the error statements without taking any inference and quickly start analysing the code maybe do some mental dry runs and whatnot.
One can easily fix an error in similar ways or in the above example by noticing an integer being converted into capital string letters which logically isn’t correct. Hence fixing this specific error without reading the error statement didn’t seem much of an issue.
However, I believe it can be concerning when programmers build up their own debugging process based on similar situations mentioned above and do not consider reading error statements. In the next part, I highlight the importance of reading error statements properly and making sense of what they mean.
Hang on with me as I explain more with an example below, consider this error:
AttributeError: ’int’ object has no attribute ‘upper’
If you read the error carefully and analyse it with a bit of curiosity, the following questions may pop up:
- What’s an ‘int’ object and why is ‘int’ an object wasn't ‘int’ a data type?
- Why does it not have an attribute named upper isn’t
upper()a method/function?
- What the hell is AttributeError and how did ‘attributes’ come into the picture?
Maybe less, maybe more but similar things popped up in my mind as I looked into it and realised how some of the major principles of the OOPS paradigm are actually applied in every little thing I have been using till now.
int commonly known as a data type is an object in python with a variety of methods defined as attributes in it like the round() method which is used for rounding a number with a specified number of decimals. Similarly, I figured there exists an upper() method which is an attribute of the ‘str’ object and this is how python generates error statements by explicitly mentioning what’s happening under the hood.
This epiphany when looking at error statements reminded me that as a programmer, one often needs to dig deep into things which seem so obvious to the eye. Ruminating over these simple observations made me think and stretch some of the most beautifully abstracted programming concepts.
Who knows what an aspiring software engineer with a cup of coffee is capable of, who would’ve thought that this simple error-handling exploration of mine would make me reiterate some of the core concepts of OOPS on a whole other level?