Update README.md

README.md

@@ -79,11 +79,13 @@ For example, I could throw an exception when a normal user enters empty fields b
 
 - Nobody cares where the error originated, whether it was in method X or Y, it doesn't matter.
 
+- It is not a *programmer mistake*. The exceptions were designed to avoid *programmer mistakes* by immediately reporting the error caused, including where it originated. Read more about it [here](https://github.com/dotnet/runtime/blob/main/docs/design/coreclr/botr/intro-to-clr.md#exceptions).
+
 And there are many more examples of errors caused by the end user: the email is duplicated or a password that does not comply with security policies, among others.
 
-I only throw exceptions when the exception object is useful to someone (like a developer); otherwise, I use a **Result object** to handle errors. I use **return statements** in my methods to create the error.
+I only throw exceptions when the exception object is useful to someone (like a developer); otherwise, I create **result objects** and use **return statements** in my methods to terminate execution immediately when an error occurs.
 
-This is just my opinion, it is not an **absolute truth** either. My point of view is more philosophical, so the purpose of my paragraphs is not to indicate the disadvantages of using exceptions, but to explain why for me it does not make sense in some cases to throw exceptions.
+This is just my opinion, it is not an absolute truth either. My point of view is more philosophical, so the purpose of my paragraphs is not to indicate the disadvantages of using exceptions, but to explain why for me it does not make sense in some cases to throw exceptions.
 
 ### Anecdote
 > At work I had to implement a module to generate a report that performs a monthly comparison of income and expenses for a company, so it was necessary to create a function that is responsible for calculating the percentage of a balance per month: