Q.Q. Nos. 20 and 21 are Assertion (A) and Reason (R) based questions. Mark the correct choice as : (A) Both Assertion (A) and Reason (R) are true and Reason (R) is the correct explanation for Assertion (A). (B) Both Assertion (A) and Reason (R) are true and Reason (R) is not the correct explanation for Assertion (A). (C) Assertion (A) is true, but Reason (R) is false. (D) Assertion (A) is false, but Reason (R) is true. Assertion (A) : [1,2,3]+'123' is an invalid expression in Python. Reason (R) : In Python, a list cannot be concatenated with a string.

TypeError Handling: A Concept-First Explanation

Think about a library. Every book belongs to a section — fiction, history, science, biography. If you walk to the history section, pull a book off the shelf, and expect it to teach you how to bake a cake, you will be disappointed. The book is the wrong type for your purpose. It is not that the book is bad; it is that you are using a history book where you needed a cookbook.

That is the core intuition behind a TypeError.

What a TypeError Actually Is

In any system that works with data — whether a computer program, a database, or even a structured form you fill out — every piece of information has a type. A name is text. A date is a date. A price is a number. A yes/no answer is a boolean (true or false).

A TypeError occurs when you try to perform an operation on a piece of data that does not make sense for its type. You are asking the system to treat something as if it were a different kind of thing.

For example, imagine a form that asks for your age. You write "twenty-five" as a word. The system expects a number. If it tries to add 1 to that word to calculate next year's age, it will fail — not because the word is wrong, but because you cannot add a number to a word. That failure is a TypeError.

Why It Matters in the Real World

TypeErrors are not just a technical nuisance. They represent a fundamental mismatch between what you intend and what the system can do. In business, finance, or administration, such mismatches can have real consequences.

Consider a bank transfer. The system expects an account number as a string of digits. If someone accidentally enters a letter, the system might throw a TypeError — or worse, it might silently misinterpret the input and send money to the wrong account. Handling TypeErrors means catching these mismatches before they cause damage.

In data analysis, a common mistake is trying to calculate an average of a column that contains text entries. The calculation fails, and the analyst must go back, clean the data, and ensure every entry in that column is actually a number.

How TypeError Handling Works

Handling a TypeError means anticipating that such mismatches can happen and building a way to respond gracefully. The goal is never to let the system crash or produce nonsense output.

There are three main strategies:

• Check before you act. Before performing an operation, verify that the data is of the expected type. If it is not, either convert it (if possible) or reject it with a clear message.
• Catch the error when it happens. If the operation fails, intercept the failure and decide what to do next — ask for correct input, skip the problematic data, or log the issue for review.
• Design to prevent mismatches. Use forms, dropdowns, and validation rules so that users can only enter data of the correct type in the first place. …