Uncaught :无法读取属性'add‘of null

Question

我是新手开发者。

在开发过程中，我们遇到了不同的错误问题。然而，对于编程新手来说，很难直接理解和解决这些问题。

我认为，错误通常与输入错误或数据结构错误或运行时内存错误有关，后者与硬件或else有关。

如何快速地解释和解决这些错误？

Answer 1

我的想法：

我不认为许多错误与打字错误有关。排字通常不会产生编译的东西，所以很少产生任何东西，甚至到了单元测试的程度，更不用说了。很少有这样的人通常很容易被发现。

在16年的开发过程中，我所看到的由硬件故障引起的唯一问题是如此严重(即系统/子系统故障)，以至于它立刻就被系统管理员发现了。一旦它达到程序员的程度，我建议你从脑海中消除硬件错误的可能性，直到你看到一些非常有力的证据表明这是事实，因为一般来说，你不应该浪费时间去思考它。

错误可分为三类：

1)误解--即系统工作正常，但有人误解了它的本意。如果是这样的话，最好的方法就是获取尽可能多的信息，最理想的方法是与实际看到错误的人交谈，并询问他们看到了什么以及他们期望看到什么。

2)配置错误--虽然由硬件错误引起的错误非常少，但就软件配置而言，由于机器设置不同而造成的错误非常多。如果您无法在您的开发设置上重现错误，这可能是非常不标准的，因为您已经安装了各种各样的工具，并且您已经做了一些更改以提高效率，这种情况尤其可能发生。这里最好的做法是有一个开发测试环境，这是一个产品的克隆，并尝试在那里复制错误。一旦你有了它，你就可以开始比较这个环境和它工作的环境，看看它们有什么不同。

3)代码错误--代码有误。有一些常见的问题(不检查返回值或处理不当的错误、不正确的循环和检查--例如，由于开发人员对其结束于I或I-1感到困惑而没有检查数组或集合中的最终记录)，但它们的常见程度因项目而异，而且在任何情况下，它们都很容易通过遍历代码来识别。我在这里要说的主要事情是确保您可以复制错误(这可能涉及从用户获取错误发生的特定记录的详细信息)并逐行执行代码。

概括地说，我建议以下几点：

1)拥有问题。这是你的问题，你需要解决它，不管它是什么，或者是谁造成的。这可能需要你去调查那些不是你的专业领域的东西，但那是你所需要的，那是你所做的。

2)与用户对话。在我的经验中，最能减缓问题解决速度的是糟糕的信息，所以直接去找用户，找出发生了什么。让他们带你走过去，他们做了什么，他们看到了什么，他们期望看到什么。问一问它是一直都在发生还是只是一些时候。如果只是一些时间，询问他们的模式，获取具体记录的细节，它发生的地方。质疑一切，什么都不想。当我对他们说话的时候，我的意思是和他们交谈--你会发现比通过电子邮件交谈更多的东西，而且你会做得更快。

3)再现问题。不要猜测解决方案，复制它，这是唯一的方式来知道你已经真正找到了发生的事情。一步一步地走代码，看看实际发生了什么。这可能涉及复制环境或获取数据库的副本--如果有必要，这就是您要做的。

4)实事求是。这不是硬件问题，编译器也没有问题。一旦你知道了这是一个真正的问题(即用户没有误解它的意思)，并且你已经复制了它，到目前为止，最可能的问题是代码是错误的，所以不要欺骗你自己。

5)解决问题的根源，而不是症状。如果他们说一切都是1，不要仅仅从所有东西中减去1，找出为什么是1，然后修正它。如果你只治好症状，你就会再次看到问题。

Answer 2

很多，更确切地说，你作为程序员所做的大部分工作都是调试。您正在调试您的代码或其他人的。作为新手，您不想专注于更快。您需要关注细节、组织和正确性：

• 研究细节。不要只是调试，要想知道为什么有些东西不起作用。
• 组织良好的代码使维护和调试更加容易。
• 正确的用法:只是为了节省时间而把代码放在一起就不会了。

另外，问questions...ask，问，问。调试的速度不像一旦找到解决错误的技巧那么重要。速度会随着时间的推移而来；然而，准确性应该是你最关心的问题。

Answer 3

我想说的是，拥有一个智能的IDE并学习如何使用调试器。如果没有这些基本的东西，您可能无法在头脑中执行代码并查看它是否有效，或者在各处插入跟踪语句。这会使调试简单的错误花费很长时间，在更好的环境中，甚至在运行项目(或之后不久)之前，都会以红光向您指出这一点。