Fixed #18387 -- Do not call sys.exit during call_command.

Moved sys.exit(1) so as failing management commands reach it
only when running from command line.

2 files changed, 11 insertions, 3 deletions

diff --git a/docs/howto/custom-management-commands.txt b/docs/howto/custom-management-commands.txt
index 2b34d35de7..4a27bdf7a9 100644
--- a/docs/howto/custom-management-commands.txt
+++ b/docs/howto/custom-management-commands.txt
@@ -317,8 +317,12 @@ Exception class indicating a problem while executing a management
 command.
 
 If this exception is raised during the execution of a management
-command, it will be caught and turned into a nicely-printed error
-message to the appropriate output stream (i.e., stderr); as a
-result, raising this exception (with a sensible description of the
+command from a command line console, it will be caught and turned into a
+nicely-printed error message to the appropriate output stream (i.e., stderr);
+as a result, raising this exception (with a sensible description of the
 error) is the preferred way to indicate that something has gone
 wrong in the execution of a command.
+
+If a management command is called from code through
+:ref:`call_command <call-command>`, it's up to you to catch the exception
+when needed.
diff --git a/docs/releases/1.5.txt b/docs/releases/1.5.txt
index 0fec53ab6d..0d86a52670 100644
--- a/docs/releases/1.5.txt
+++ b/docs/releases/1.5.txt
@@ -75,6 +75,10 @@ Django 1.5 also includes several smaller improvements worth noting:
 
 * The generic views support OPTIONS requests.
 
+* 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.
+
 * The dumpdata management command outputs one row at a time, preventing
   out-of-memory errors when dumping large datasets.