设计异常信息并不容易，因为它们总是被用在压力条件下。其内容，必须在给出足够信息量和找到异常原因之间取得一个微妙平衡，而不是给出大量信息导致迷惑或是让用户承受更大压力。

在 Symfony 3.3 中我们 redesigned the web exceptions 而在 Symfony 3.4 中，我们将在 console exceptions 中做同样的事。原来的异常存在的主要问题在于，仅解释发生了什么，忽略了在哪里发生的异常。例如，看一下这个 Symfony console exception:

1
2

[Symfony\Component\Debug\Exception\ContextErrorException]
Notice: Undefined variable: b

问题被很好地解释了，确切的异常类也包括进来了，但是错误是在哪里发生的呢？哪个文件、哪一行才是你应去寻找并修复的呢？如果你 在冗长模式下运行命令，就会看到确切的文件和行号，但那通常意味着你使用了 -v 选项来运行命令。

重复执行一条命令并不总是可能的或方便的：也许错误发生在一个长久运行的命令执行的10分钟之后，或是仅发生在命令行对数据库进行修改之前的最初执行阶段，或者在一个无人执守的Cron任务过程中。

现在看一下 Symfony 3.4 中所显示的同一个异常:

1
2

In CacheClearCommand.php line 88:
Notice: Undefined variable: b

Console exceptions 现在显示出发生了错误的确切文件和行号，不管命令的 verbosity 是什么情形。再有，异常所在的类默认不再显示，因为在多数时候它已不是那么有用。在冗长模式下（verbose mode）还是会显示 exception class。

这个新行为的唯一例外，是 Symfony Console component 的内部异常。此时显示文件和行号并没有什么用，因为那已是你的职责之外的事，毋须你去改变。因此，与其这样:

1
2
3
4

In Application.php line 615:
Command "foo" is not defined.
Did you mean this?
  app:foo

你将继续看到下面这样的内部异常:

1
2
3

Command "foo" is not defined.
Did you mean this?
  app:foo