Use @Error instead of celery.exceptions.Error

docs/configuration.rst

@@ -1114,7 +1114,7 @@ This setting defines what happens when a task part of a chord raises an
 exception:
 
 - If propagate is True the chord callback will change state to FAILURE
-  with the exception value set to a :exc:`~celery.exceptions.ChordError`
+  with the exception value set to a :exc:`~@ChordError`
   instance containing information about the error and the task that failed.
 
     This is the default behavior in Celery 3.1+

docs/history/changelog-3.0.rst

@@ -855,7 +855,7 @@ If you're looking for versions prior to 3.0.x you should go to :ref:`history`.
     Fix contributed by Bryan Bishop.
     Congratulations on opening bug #1000!
 
-- Tasks that raise :exc:`~celery.exceptions.Ignore` are now acknowledged.
+- Tasks that raise :exc:`~@Ignore` are now acknowledged.
 
 - Beat: Now shows the name of the entry in ``sending due task`` logs.
 
@@ -909,7 +909,7 @@ If you're looking for versions prior to 3.0.x you should go to :ref:`history`.
 
     Fix contributed by Sam Cooke.
 
-- Tasks can now raise :exc:`~celery.exceptions.Ignore` to skip updating states
+- Tasks can now raise :exc:`~@Ignore` to skip updating states
   or events after return.
 
     Example:
@@ -1184,14 +1184,14 @@ If you're looking for versions prior to 3.0.x you should go to :ref:`history`.
   :mod:`celery.task` modules.
 
 - Terminating a task now results in
-  :exc:`~celery.exceptions.RevokedTaskError` instead of a ``WorkerLostError``.
+  :exc:`~@RevokedTaskError` instead of a ``WorkerLostError``.
 
 - ``AsyncResult.revoke`` now accepts ``terminate`` and ``signal`` arguments.
 
 - The :event:`task-revoked` event now includes new fields: ``terminated``,
   ``signum``, and ``expired``.
 
-- The argument to :class:`~celery.exceptions.TaskRevokedError` is now one
+- The argument to :class:`~@TaskRevokedError` is now one
   of the reasons ``revoked``, ``expired`` or ``terminated``.
 
 - Old Task class does no longer use classmethods for push_request and
@@ -2067,7 +2067,7 @@ See :ref:`whatsnew-3.0`.
     Fix contributed by Bryan Bishop.
     Congratulations on opening bug #1000!
 
-- Tasks that raise :exc:`~celery.exceptions.Ignore` are now acknowledged.
+- Tasks that raise :exc:`~@Ignore` are now acknowledged.
 
 - Beat: Now shows the name of the entry in ``sending due task`` logs.
 
@@ -2121,7 +2121,7 @@ See :ref:`whatsnew-3.0`.
 
     Fix contributed by Sam Cooke.
 
-- Tasks can now raise :exc:`~celery.exceptions.Ignore` to skip updating states
+- Tasks can now raise :exc:`~@Ignore` to skip updating states
   or events after return.
 
     Example:
@@ -2396,14 +2396,14 @@ See :ref:`whatsnew-3.0`.
   :mod:`celery.task` modules.
 
 - Terminating a task now results in
-  :exc:`~celery.exceptions.RevokedTaskError` instead of a ``WorkerLostError``.
+  :exc:`~@RevokedTaskError` instead of a ``WorkerLostError``.
 
 - ``AsyncResult.revoke`` now accepts ``terminate`` and ``signal`` arguments.
 
 - The :event:`task-revoked` event now includes new fields: ``terminated``,
   ``signum``, and ``expired``.
 
-- The argument to :class:`~celery.exceptions.TaskRevokedError` is now one
+- The argument to :class:`~@TaskRevokedError` is now one
   of the reasons ``revoked``, ``expired`` or ``terminated``.
 
 - Old Task class does no longer use classmethods for push_request and

docs/userguide/canvas.rst

@@ -754,7 +754,7 @@ the exception value will be forwarded to the chord callback.
 
 From 3.1 errors will propagate to the callback, so the callback will not be executed
 instead the callback changes to failure state, and the error is set
-to the :exc:`~celery.exceptions.ChordError` exception:
+to the :exc:`~@ChordError` exception:
 
 .. code-block:: python
 
@@ -782,7 +782,7 @@ find the original traceback in ``result.traceback``.
 
 Note that the rest of the tasks will still execute, so the third task
 (``add.s(8, 8)``) is still executed even though the middle task failed.
-Also the :exc:`~celery.exceptions.ChordError` only shows the task that failed
+Also the :exc:`~@ChordError` only shows the task that failed
 first (in time): it does not respect the ordering of the header group.
 
 .. _chord-important-notes:

docs/userguide/tasks.rst

@@ -319,7 +319,7 @@ Here's an example using ``retry``:
 .. note::
 
     The :meth:`~@Task.retry` call will raise an exception so any code after the retry
-    will not be reached.  This is the :exc:`~@RetryTaskError`
+    will not be reached.  This is the :exc:`~@Retry`
     exception, it is not handled as an error but rather as a semi-predicate
     to signify to the worker that the task is to be retried,
     so that it can store the correct state when a result backend is enabled.
@@ -341,7 +341,7 @@ but this will not happen if:
 
 - An ``exc`` argument was not given.
 
-    In this case the :exc:`celery.exceptions.MaxRetriesExceeded`
+    In this case the :exc:`~@MaxRetriesExceeded`
     exception will be raised.
 
 - There is no current exception