事情的起因与经过
我们公司的合作伙伴使用我们的实时数据库做一个数据中心的项目，项目使用DotNet开发。合作伙伴的公司有一个员工专门负责封装数据层--对实时数据库的增删改查的封装。
但是这个人的脾气有点怪，或者说有点傲气，一段时间下来，只要他遇到操作数据库的问题，大部分归结于数据库或者我们提供的DotNetSDK的问题。无论是他不会使用的问题，还是确实是我们产品的问题，我们基本上每次都会远程或者直接到他公司去给他解决问题。
就这样持续了大概一年的的时间，直到前段时间他遇到一个问题：调用DotNetSDK的一个方法时，根据传入参数的不同会出现有时正常，有时会抛出一个”找不到DotNetSDK程序集”的异常。
后来同事远程给他查看问题，发现他是使用Remoting的技术进行远程调用，而真正调用DotNetSDK的地方是服务端，出现”找不到DotNetSDK程序集”的异常为客户端。
客户端出现异常后，查看异常的详细信息为”无法进行反序列化”。查资料了解后，应该是Remoting无法对异常、null进行序列化反序列化。
当服务端调用DotNetSDK时，传入了无效的参数，DotNetSDK会抛出异常，而服务端并没有对异常进行捕捉，导致异常通过Remoting返回到客户端，而由于Remoting不能对异常反序列化，所以导致客户端抛出异常，至于为什么异常的标题是”找不到DotNetSDK程序集”，就不清楚原因了。
找到问题的原因后，给对方的开发人员解释这属于Remoting调用的问题，和DotNetSDK无关。但是不清楚对方的开发人员是不了解Remoting调用还是其他原因，他就一口咬定是DotNetSDK出了问题。
没办法，我们让他在服务端调用DotNetSDK的地方加入了try catch，并在catch中将异常信息记录到日志中。
运行了一次，查看日志，记录的异常信息为”无效的参数”。
这样，通过这个日志信息，我们证明了我们的DotNetSDK并没有问题，而是他的Remoting调用的问题。对方的开发人员总算承认不是DotNetSDK的问题了，这时候给他讲Remoting的事情，他才总算稍稍认可。
就是这样一个事情，我们向领导汇报后，领导把我们批了一顿“你们之所以和对方的开发人员，关系处理的这么紧张、不舒服，就是因为出现问题后，你们总是想证明是别人的错。加上他这个人是个比较傲气的人，他可能觉得在他们公司，他是DotNet技术最牛的一个，可是被你们证明他错了，那么他心里自然不舒服了。时间长了， 次数多了，你们之间的关系自然会紧张了。像这种情况，最好的办法就是，你能证明自己是清白的，也能间接提高对方的技术水平。”
退而次之，如果做不到上面那点，可以这样：找到问题原因后，不要说你这个地方的代码不能这么写，要改成怎样怎样，那个地方的代码不能那么些，要怎样怎样。而是应该说：我也不知道改了什么地方，它就好了。如果对方有心，他自然会比较原来的代码，你改了什么地方。进而他回去了解你用了什么技术。如果他无心，你想要证明他错了，那么情况也不会好到什么地方去。
总结
不要证明别人是错的，只需要证明自己没有错。当你证明别人是错的时候，你就输了。你赢的了芝麻，却输了西瓜；你证明别人错了，那么也就留下了与人相处关系紧张的问题。
遇到问题，只需证明自己是清白的，同时能间接提高对方的技术水平，那就最好不过了。
这应该是很高的境界了吧，值得吾辈深刻学习。