Made CommandError use the exception directive in docs.

docs/howto/custom-management-commands.txt

@@ -87,9 +87,9 @@ The new custom command can be called using ``python manage.py closepoll
 
 The ``handle()`` method takes one or more ``poll_ids`` and sets ``poll.opened``
 to ``False`` for each one. If the user referenced any nonexistent polls, a
-:class:`CommandError` is raised. The ``poll.opened`` attribute does not exist
+:exc:`CommandError` is raised. The ``poll.opened`` attribute does not exist in
-in the :doc:`tutorial</intro/tutorial01>` and was added to
+the :doc:`tutorial</intro/tutorial01>` and was added to ``polls.models.Poll``
-``polls.models.Poll`` for this example.
+for this example.
 
 .. _custom-commands-options:
 
@@ -254,7 +254,7 @@ All attributes can be set in your derived class and can be used in
     This option can't be ``False`` when the
     :data:`~BaseCommand.can_import_settings` option is set to ``False`` too
     because attempting to set the locale needs access to settings. This
-    condition will generate a :class:`CommandError`.
+    condition will generate a :exc:`CommandError`.
 
 .. attribute:: BaseCommand.style
 
@@ -304,7 +304,7 @@ the :meth:`~BaseCommand.handle` method must be implemented.
 
     Tries to execute this command, performing system checks if needed (as
     controlled by the :attr:`requires_system_checks` attribute). If the command
-    raises a :class:`CommandError`, it's intercepted and printed to stderr.
+    raises a :exc:`CommandError`, it's intercepted and printed to stderr.
 
 .. admonition:: Calling a management command in your code
 
@@ -321,7 +321,7 @@ the :meth:`~BaseCommand.handle` method must be implemented.
 .. method:: BaseCommand.check(app_configs=None, tags=None, display_num_errors=False)
 
     Uses the system check framework to inspect the entire Django project for
-    potential problems. Serious problems are raised as a :class:`CommandError`;
+    potential problems. Serious problems are raised as a :exc:`CommandError`;
     warnings are output to stderr; minor notifications are output to stdout.
 
     If ``app_configs`` and ``tags`` are both ``None``, all system checks are
@@ -361,12 +361,10 @@ Rather than implementing :meth:`~BaseCommand.handle`, subclasses must implement
     Perform the command's actions for ``label``, which will be the string as
     given on the command line.
 
-.. _ref-command-exceptions:
-
 Command exceptions
 ------------------
 
-.. class:: CommandError
+.. exception:: CommandError
 
 Exception class indicating a problem while executing a management command.
 

docs/ref/django-admin.txt

@@ -1551,7 +1551,7 @@ Example usage::
     django-admin migrate --traceback
 
 By default, ``django-admin`` will show a simple error message whenever a
-:class:`~django.core.management.CommandError` occurs, but a full stack trace
+:exc:`~django.core.management.CommandError` occurs, but a full stack trace
 for any other exception. If you specify ``--traceback``, ``django-admin``
 will also output a full stack trace when a ``CommandError`` is raised.
 

docs/releases/1.5.txt

@@ -255,7 +255,7 @@ Django 1.5 also includes several smaller improvements worth noting:
 
 * Management commands do not raise ``SystemExit`` any more when called by code
   from :ref:`call_command <call-command>`. Any exception raised by the command
-  (mostly :ref:`CommandError <ref-command-exceptions>`) is propagated.
+  (mostly :exc:`~django.core.management.CommandError`) is propagated.
 
   Moreover, when you output errors or messages in your custom commands, you
   should now use ``self.stdout.write('message')`` and

docs/releases/1.7.txt

@@ -1306,7 +1306,7 @@ Miscellaneous
   to manually delete objects from deleted forms.
 
 * Loading empty fixtures emits a ``RuntimeWarning`` rather than raising
-  :class:`~django.core.management.CommandError`.
+  :exc:`~django.core.management.CommandError`.
 
 * :func:`django.contrib.staticfiles.views.serve` will now raise an
   :exc:`~django.http.Http404` exception instead of