unify exception usages

book/internals.rst

@@ -177,12 +177,12 @@ Event):
 #. Listeners of the ``kernel.terminate`` event can perform tasks after the
    Response has been served.
 
-If an Exception is thrown during processing, the ``kernel.exception`` is
-notified and listeners are given a chance to convert the Exception to a
+If an exception is thrown during processing, the ``kernel.exception`` is
+notified and listeners are given a chance to convert the exception into a
 Response. If that works, the ``kernel.response`` event is notified; if not, the
 Exception is re-thrown.
 
-If you don't want Exceptions to be caught (for embedded requests for
+If you don't want exceptions to be caught (for embedded requests for
 instance), disable the ``kernel.exception`` event by passing ``false`` as the
 third argument to the ``handle()`` method.
 
@@ -396,7 +396,7 @@ forwards the ``Request`` to a given Controller (the value of the
 ``class::method`` notation).
 
 A listener on this event can create and set a ``Response`` object, create
-and set a new ``Exception`` object, or do nothing::
+and set a new ``Exception`` object or do nothing::
 
     use Symfony\Component\HttpKernel\Event\GetResponseForExceptionEvent;
     use Symfony\Component\HttpFoundation\Response;

components/console/helpers/dialoghelper.rst

@@ -95,7 +95,7 @@ convenient for passwords::
     When you ask for a hidden response, Symfony will use either a binary, change
     stty mode or use another trick to hide the response. If none is available,
     it will fallback and allow the response to be visible unless you pass ``false``
-    as the third argument like in the example above. In this case, a RuntimeException
+    as the third argument like in the example above. In this case, a ``RuntimeException``
     would be thrown.
 
 Validating the Answer

cookbook/bundles/best_practices.rst

@@ -166,7 +166,7 @@ Commands, Helpers, Listeners, and Controllers.
 Classes that connect to the event dispatcher should be suffixed with
 ``Listener``.
 
-Exceptions classes should be stored in an ``Exception`` sub-namespace.
+Exception classes should be stored in an ``Exception`` sub-namespace.
 
 Vendors
 -------

cookbook/console/logging.rst

@@ -14,8 +14,9 @@ output and process it. This can be especially handful if you already have
 some existing setup for aggregating and analyzing Symfony logs.
 
 There are basically two logging cases you would need:
- * Manually logging some information from your command;
- * Logging uncaught Exceptions.
+
+* Manually logging some information from your command;
+* Logging uncaught exceptions.
 
 Manually Logging from a Console Command
 ---------------------------------------

cookbook/email/spool.rst

@@ -20,7 +20,7 @@ Spool Using Memory
 
 When you use spooling to store the emails to memory, they will get sent right
 before the kernel terminates. This means the email only gets sent if the whole
-request got executed without any unhandled Exception or any errors. To configure
+request got executed without any unhandled exception or any errors. To configure
 swiftmailer with the memory option, use the following configuration:
 
 .. configuration-block::

cookbook/service_container/event_listener.rst

@@ -10,7 +10,7 @@ component and can be viewed in the :class:`Symfony\\Component\\HttpKernel\\Kerne
 
 To hook into an event and add your own custom logic, you have to create
 a service that will act as an event listener on that event. In this entry,
-you will create a service that will act as an Exception Listener, allowing
+you will create a service that will act as an exception listener, allowing
 you to modify how exceptions are shown by your application. The ``KernelEvents::EXCEPTION``
 event is just one of the core kernel events::