这是 Python 之禅特别系列的一部分，重点是第十和第十一条原则：沉默的错误（或不沉默）。

处理“异常情况”是编程中争论最多的问题之一。这可能是因为风险很大：处理不当的错误值甚至可以使庞大的系统瘫痪。由于“异常情况”从本质上来说，是测试不足的，但发生的频率却令人不快，因此，是否正确处理它们往往可以将一个噩梦般的系统与一个“可以工作”的系统区分开来。

从 Java 的 checked 异常，到 Erlang 的故障隔离，再到 Haskell 的 Maybe，不同的语言对错误处理的态度截然不同。

这两条 Python 之禅是 Python 对这个话题的冥思。

错误绝不应该悄悄传递... Errors should never pass silently…

当 Python 之禅在 Tim Peters 眼里闪烁而出之前，在维基百科被俗称为“维基”之前，第一个维基网站 C2 就已经存在了，它是一个编程指南的宝库。这些原则大多来自于 Smalltalk 编程社区。Smalltalk 的思想影响了许多面向对象的语言，包括 Python。

C2 维基定义了 武士原则 Samurai Principle ：“胜利归来，要么不归。”用 Python 人的术语来说，它鼓励摒弃 哨兵值 sentinel value ，比如用返回 None 或 -1 来表示无法完成任务，而是采用引发异常的方式。一个 None 是无声的：它看起来像一个值，可以放在一个变量中，然后到处传递。有时，它甚至是一个有效的返回值。

这里的原则是，如果一个函数不能完成它的契约，它应该“高调失败”：引发一个异常。所引发的异常永远不会看起来像是一个可能的值。它将跳过 returned_value = call_to_function(parameter) 行，并上升到调用栈中，可能使程序崩溃。

崩溃的调试是很直接的：有一个堆栈跟踪来指示问题以及调用堆栈。崩溃可能意味着程序的必要条件没有满足，需要人为干预。它可能意味着程序的逻辑有问题。无论是哪种情况，高调失败都比一个隐藏的、“缺失”的值要好。用 None 来感染程序的有效数据，直到它被用在某个地方，就如你可能已经知道的，错误信息会说 “None 没有方法进行拆分”。

除非显式消除 Unless explicitly silenced

有时需要显式地捕获异常。我们可能会预见到文件中的某些行格式错误，并希望以特殊的方式来处理它们，也许可以把它们放在一个“需要人来看看的行”的文件中，而不是让整个程序崩溃。

Python 允许我们用 except 来捕获异常。这意味着错误可以被显式消除。这种明确性意味着 except 行在代码审查中是可见的。质疑为什么应该在这里显式消除异常并从异常中恢复，是有意义的。自问一下我们是否捕获了太多或太少的异常也是有意义的。

因为这些全都是明确的，所以有人可以阅读代码并了解哪些异常是可以恢复的。

via: https://opensource.com/article/19/12/zen-python-errors

作者：Moshe Zadka 选题：lujun9972 译者：wxy 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

诀窍就是同一个错误不要犯两次。

到目前为止，我已做了十多年 Fedora 贡献者。 Fedora 有一个由开发者和用户组成的大型社区，其中每一个人，不管是极富洞察力的用户还是出色的程序员，都有一些独有的技能。我喜欢这样的社区，因为它能激励我培养自己的新技能。

对我来说，培养技能最好的方法就是犯错，比如把事情搞得一团糟。犯什么样的错误不重要，因为相比错误本身，我在脱离困境的过程里学习到了什么更重要。

为什么犯错误是好事

我依然记得我犯的第一个计算机错误。我家的第一台电脑是我叔叔升职后送个我们的爱普生笔记本电脑，它有一个特别快的 10 MHz 处理器，因为太重了，所以还有一个手提把手。我很喜欢它。

它运行 DOS，但有一个基于文本的菜单应用，所以对新手用户比较友好。硬盘菜单有十个“页面”，每个“页面”可以配置十个命令。我们有一个游戏页面，还有一个页面放些“无聊的东西”，比如文字处理程序和电子表格等等。

硬盘菜单还有一些其他功能，当我玩腻了游戏，就会去探索它们。有一天，我决定使用菜单的账户功能。账户不会改变出现的应用程序，但在某种程度上，可以防止对应用程序未经授权的访问。你可以直接跳到 DOS 中取代它，但使用账户仍然是一个不错的尝试。

我为自己、父母和妹妹创建了账户。虽然我父母有点不开心，但他们最终迁就了我。万事顺遂了一段时间后，妹妹忘记了她的账户密码。于是，我父母让我删掉她的密码，但是没有妹妹的密码去登录账户，我就无法删除她的密码（那是在 90 年代初，一个比现在简单得多的时代）。要怎么办？要怎么办？

那以后一段时间，我们一直试着猜测密码，直到有一天，我决定尝试做一些我还没有做过的事情。当我第一次创建帐户时，我设置了一个主密码。如果我输入主密码来代替我妹妹的密码，会发生什么呢？

如果你在想，“这当然不会有用的”，那么显然你不熟悉 90 年代安全策略的天真幼稚。有了主密码（顺便说一下，主密码是 “worf” ，指的是企业号星舰的克林贡人安全主管，如果你不是《星际迷航：下一代》粉丝的话），我可以删除所有密码。于是，家里的每个人又都可以毫无障碍地使用电脑了。

试运行的重要性

在那之后，我又犯了更大更有益的错误。比如，在我第一次做系统管理员时，当时我正整理一些数据以重新配置存储阵列。有一次，我意外地颠倒了源路径和目标路径，而且那是一个带有 ——delete 标志的 rsync 命令。真的是太糟糕了!

幸运的是，我自己的账户也崩溃了，这让我的道歉更容易被其他受影响的用户接受。对我们所有人来说更幸运的是，我们有备份。所以那天结束的时候，每个人的文件都找回来了，我还学到了一个宝贵的教训，那就是在进行破坏性同步之前，先使用 --dry-run 标志试运行。

以正确的方式处理错误

我不介意犯错误。这些年来，我积累了很多实践经验，学到的诀窍就是不要犯同样的错误。从错误中学习能让我在技能和事业上取得进步，并发现新的会犯的错误。作为 Linux 系统管理员，我总是试图在一个安全的环境（测试平台就很好）中犯错误，确保我可以从错误中恢复（备份真的非常非常重要！），并给以后的我留个笔记，这样他就不会重复犯错（文档是你的朋友）。当然，还要勇于承认自己的错误，并在出现问题时清楚地与用户沟通。如果我一直这样做，也许有一天我就会觉得我很清楚我在做什么！

via: https://opensource.com/article/20/8/sysadmin-mistakes

作者：Ben Cotton 选题：lujun9972 译者：Starryi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

过去，我已经讨论了许多 Ubuntu 更新错误。如果你使用命令行更新 Ubuntu，那可能会遇到一些“错误”。

其中一些“错误”基本上是内置功能，可防止对系统进行不必要的更改。在本教程中，我不会涉及那些细节。

在本文中，我将向你展示如何解决在更新系统或安装新软件时可能遇到的以下错误：

Reading package lists… Error!
E: Unable to parse package file /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_bionic_InRelease
E: The package lists or status file could not be parsed or opened.

在 Debian 中可能会遇到类似的错误：

E: Unable to parse package file /var/lib/apt/extended_states (1)

即使遇到 The package cache file is corrupted 也完全不必惊慌。这真的很容易“修复”。

在基于 Ubuntu 和 Debian 的 Linux 发行版中处理 “Unable to parse package file” 错误

以下是你需要做的。仔细查看 Ubuntu 报错文件的名称和路径。

Reading package lists… Error!
E: Unable to parse package file /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_bionic_InRelease
E: The package lists or status file could not be parsed or opened.

例如，上面的错误是在报 /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_bionic_InRelease 文件错误。

这让你想到这个文件不正确。现在，你需要做的就是删除该文件并重新生成缓存。

sudo rm <file_that_is_not_parsed>

因此，这里我可以使用以下命令：sudo rm /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_bionic_InRelease，然后使用 sudo apt update 命令重建缓存。

给初学者的分步指导

如果你熟悉 Linux 命令，那么可能知道如何使用绝对路径删除文件。对于新手用户，让我指导你安全删除文件。

首先，你应该进入文件目录：

cd /var/lib/apt/lists/

现在删除无法解析的文件：

sudo rm archive.ubuntu.com_ubuntu_dists_bionic_InRelease

现在，如果你再次运行更新，将重新生成 apt 缓存。

sudo apt update

有很多文件无法解析？

如果你在更新系统时有一个或两个文件无法解析，那么问题不大。但是，如果系统报错有十个或二十个此类文件，那么一一删除它们就太累了。

在这种情况下，你可以执行以下操作来删除整个缓存，然后再次生成它：

sudo rm -r /var/lib/apt/lists/*
sudo apt update

解释这为何能解决问题

/var/lib/apt 是与 apt 软件包管理器相关的文件和数据的存储目录。/var/lib/apt/lists 是用于保存系统 source.list 中指定的每个软件包资源信息的目录。

简单点来说，/var/lib/apt/lists 保存软件包信息缓存。当你要安装或更新程序时，系统会在此目录中检查该软件包中的信息。如果找到了该包的详细信息，那么它将进入远程仓库并实际下载程序或其更新。

当你运行 sudo apt update 时，它将构建缓存。这就是为什么即使删除 /var/lib/apt/lists 目录中的所有内容，运行更新也会建立新的缓存的原因。

这就是处理文件无法解析问题的方式。你的系统报某个软件包或仓库信息以某种方式损坏（下载失败或手动更改 sources.list）。删除该文件（或所有文件）并重建缓存即可解决此问题。

仍然有错误？

这应该能解决你的问题。但是，如果问题仍然存在，或者你还有其他相关问题，请在评论栏告诉我，我将尽力帮助你。

via: https://itsfoss.com/unable-to-parse-package-file/

作者：Abhishek Prakash 选题：lujun9972 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

自我更新 Arch Linux 桌面以来已经有一个月了。今天我试着更新我的 Arch Linux 系统，然后遇到一个错误 “error：failed to commit transaction (conflicting files) stfl：/usr/lib/libstfl.so.0 exists in filesystem”。看起来是 pacman 无法更新一个已经存在于文件系统上的库 (/usr/lib/libstfl.so.0)。如果你也遇到了同样的问题，下面是一个快速解决方案。

解决 Arch Linux 中出现的 “error：failed to commit transaction (conflicting files)”

有三种方法。

1。简单在升级时忽略导致问题的 stfl 库并尝试再次更新系统。请参阅此指南以了解 如何在更新时忽略软件包。

2。使用命令覆盖这个包：

$ sudo pacman -Syu --overwrite /usr/lib/libstfl.so.0

3。手工删掉 stfl 库然后再次升级系统。请确保目标包不被其他任何重要的包所依赖。可以通过去 archlinux.org 查看是否有这种冲突。

$ sudo rm /usr/lib/libstfl.so.0

现在，尝试更新系统：

$ sudo pacman -Syu

我选择第三种方法，直接删除该文件然后升级 Arch Linux 系统。很有效！

希望本文对你有所帮助。还有更多好东西。敬请期待！

干杯！

via: https://www.ostechnix.com/how-to-solve-error-failed-to-commit-transaction-conflicting-files-in-arch-linux/

作者：SK 选题：lujun9972 译者：lujun9972 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

如何在崩溃的局面中集中精力寻找解决方案。

如果你在 IT 领域工作，你知道事情永远不会像你想象的那样完好。在某些时候，你会遇到错误或出现问题，你最终必须解决问题。这就是系统管理员的工作。

作为人类，我们都会犯错误。我们不是已经犯错，就是即将犯错。结果，我们最终还必须解决自己的错误。总是这样。我们都会失误、敲错字母或犯错。

作为一名年轻的系统管理员，我艰难地学到了这一课。我犯了一个大错。但是多亏了上级的指导，我学会了不去纠缠于我的错误，而是制定一个“错误策略”来做正确的事情。从错误中吸取教训。克服它，继续前进。

我的第一份工作是一家小公司的 Unix 系统管理员。真的，我是一名生嫩的系统管理员，但我大部分时间都独自工作。我们是一个小型 IT 团队，只有我们三个人。我是 20 或 30 台 Unix 工作站和服务器的唯一系统管理员。另外两个支持 Windows 服务器和桌面。

任何阅读这篇文章的系统管理员都不会对此感到意外，作为一个不成熟的初级系统管理员，我最终在错误的目录中运行了 rm 命令——作为 root 用户。我以为我正在为我们的某个程序删除一些陈旧的缓存文件。相反，我错误地清除了 /etc 目录中的所有文件。糟糕。

我意识到犯了错误是看到了一条错误消息，“rm 无法删除某些子目录”。但缓存目录应该只包含文件！我立即停止了 rm 命令，看看我做了什么。然后我惊慌失措。一下子，无数个想法涌入了我的脑中。我刚刚销毁了一台重要的服务器吗？系统会怎么样？我会被解雇吗？

幸运的是，我运行的是 rm * 而不是 rm -rf *，因此我只删除了文件。子目录仍在那里。但这并没有让我感觉更好。

我立刻去找我的主管告诉她我做了什么。她看到我对自己的错误感到愚蠢，但这是我犯的。尽管紧迫，她花了几分钟时间跟我做了一些指导。 她说：“你不是第一个这样做的人，在你这种情况下，别人会怎么做？”这帮助我平静下来并专注。我开始更少考虑我刚刚做的愚蠢事情，而更多地考虑我接下来要做的事情。

我做了一个简单的策略：不要重启服务器。使用相同的系统作为模板，并重建 /etc 目录。

制定了行动计划后，剩下的就很容易了。只需运行正确的命令即可从另一台服务器复制 /etc 文件并编辑配置，使其与系统匹配。多亏了我对所有东西都做记录的习惯，我使用已有的文档进行最后的调整。我避免了完全恢复服务器，这意味着一个巨大的宕机事件。

可以肯定的是，我从这个错误中吸取了教训。在接下来作为系统管理员的日子中，我总是在运行任何命令之前确认我所在的目录。

我还学习了构建“错误策略”的价值。当事情出错时，恐慌并思考接下来可能发生的所有坏事是很自然的。这是人性。但是制定一个“错误策略”可以帮助我不再担心出了什么问题，而是专注于让事情变得更好。我仍然会想一下，但是知道我接下来的步骤可以让我“克服它”。

via: https://opensource.com/article/18/7/my-first-sysadmin-mistake

作者：Jim Hall 选题：lujun9972 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

在过去的几个星期，（几乎）每次都有消息 Ubuntu 15.04在启动时检测到系统程序错误 跑出来“欢迎”我。那时我是直接忽略掉它的，但是这种情况到了某个时刻，它就让人觉得非常烦人了！

检测到系统程序错误(System program problem detected)

你想立即报告这个问题吗？

我肯定地知道如果你是一个Ubuntu用户，你可能曾经也遇到过这个恼人的弹窗。在本文中，我们将探讨在Ubuntu 14.04和15.04中遇到"检测到系统程序错误(system program problem detected)"时 应该怎么办。

怎么解决Ubuntu中"检测到系统程序错误"的错误

那么这个通知到底是关于什么的？

大体上讲，它是在告知你，你的系统的一部分崩溃了。可别因为“崩溃”这个词而恐慌。这不是一个严重的问题，你的系统还是完完全全可用的。只是在之前的某个时刻某个程序崩溃了，而Ubuntu想让你决定要不要把这个问题报告给开发者，这样他们就能够修复这个问题。

那么，我们点了“报告错误”的按钮后，它以后就不再显示了？

不，不是的！即使你点了“报告错误”按钮，最后你还是会被一个如下的弹窗再次“欢迎”一下：

对不起，Ubuntu发生了一个内部错误是个Apport（LCTT 译注：Apport是Ubuntu中错误信息的收集报告系统，详见Ubuntu Wiki中的Apport篇），它将会进一步的打开网页浏览器，然后你可以通过登录或创建Launchpad帐户来填写一份漏洞（Bug)报告文件。你看，这是一个复杂的过程，它要花整整四步来完成。

但是我想帮助开发者，让他们知道这个漏洞啊 !

你这样想的确非常地周到体贴,而且这样做也是正确的。但是这样做的话，存在两个问题。第一，存在非常高的概率，这个漏洞已经被报告过了；第二，即使你报告了个这次崩溃，也无法保证你不会再看到它。

那么，你的意思就是说别报告这次崩溃了？

对，也不对。如果你想的话，在你第一次看到它的时候报告它。你可以在上面图片显示的“显示细节（Show Details)”中，查看崩溃的程序。但是如果你总是看到它，或者你不想报告漏洞（Bug)，那么我建议你还是一次性摆脱这个问题吧。

修复Ubuntu中“检测到系统程序错误”的错误

这些错误报告被存放在Ubuntu中目录/var/crash中。如果你翻看这个目录的话，应该可以看到有一些以crash结尾的文件。

我的建议是删除这些错误报告。打开一个终端，执行下面的命令：

sudo rm /var/crash/*

这个操作会删除所有在/var/crash目录下的所有内容。这样你就不会再被这些报告以前程序错误的弹窗所扰。但是如果又有一个程序崩溃了，你就会再次看到“检测到系统程序错误”的错误。你可以再次删除这些报告文件，或者你可以禁用Apport来彻底地摆脱这个错误弹窗。

彻底地摆脱Ubuntu中的系统错误弹窗

如果你这样做，系统中任何程序崩溃时，系统都不会再通知你。如果你想问问我的看法的话，我会说，这不是一件坏事，除非你愿意填写错误报告。如果你不想填写错误报告，那么这些错误通知存不存在都不会有什么区别。

要禁止Apport，并且彻底地摆脱Ubuntu系统中的程序崩溃报告，打开一个终端，输入以下命令：

gksu gedit /etc/default/apport

这个文件的内容是：

# 设置0表示禁用Apportw，或者1开启它。
# 你可以用下面的命令暂时关闭它：
# sudo service apport start force_start=1
enabled=1

把enabled=1改为enabled=0。保存并关闭文件。完成之后你就再也不会看到弹窗报告错误了。很显然，如果我们想重新开启错误报告功能，只要再打开这个文件，把enabled设置为1就可以了。

你的有效吗？

我希望这篇教程能够帮助你修复Ubuntu 14.04和Ubuntu 15.04中检测到系统程序错误的问题。如果这个小窍门帮你摆脱了这个烦人的问题，请让我知道。

via: http://itsfoss.com/how-to-fix-system-program-problem-detected-ubuntu/

作者：Abhishek 译者：XLCYun 校对：wxy

本文由 LCTT 原创翻译，Linux中国 荣誉推出