The current documentation for writable.write only specifies that the
callback is called "once the data has been fully handled".  It is
ambiguous whether this means "successfully handled" and, if so,
whether the callback is called if the data can not be successfully
handled (i.e. an error occurs).

The ambiguity is not only in the documentation.  The stream class
implementations differ on this point.  stream.Writable invokes the
callback with any errors that occur during parameter checking or
during calls to _write.  However, not all classes return all errors
to _write. zlib.Zlib does pass argument and state errors to the
_write (_transform) callback, but does not pass data errors.
http.OutgoingMessage passes argument type errors and some other types
of errors, but not all.

This inconsistency is behind issue #1746 and, I suspect, other issues
in client code which passes a callback to write.

This commit takes no position on whether the callback error behavior
should changed, but simply attempts to document the current behavior
in a way that is open to changes so that users are not caught by
surprise.

PR-URL: #4810
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Jeremy Whitlock <jcscoobyrs@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>

The current documentation for writable.write only specifies that the
callback is called "once the data has been fully handled".  It is
ambiguous whether this means "successfully handled" and, if so,
whether the callback is called if the data can not be successfully
handled (i.e. an error occurs).

The ambiguity is not only in the documentation.  The stream class
implementations differ on this point.  stream.Writable invokes the
callback with any errors that occur during parameter checking or
during calls to _write.  However, not all classes return all errors
to _write. zlib.Zlib does pass argument and state errors to the
_write (_transform) callback, but does not pass data errors.
http.OutgoingMessage passes argument type errors and some other types
of errors, but not all.

This inconsistency is behind issue #1746 and, I suspect, other issues
in client code which passes a callback to write.

This commit takes no position on whether the callback error behavior
should changed, but simply attempts to document the current behavior
in a way that is open to changes so that users are not caught by
surprise.

PR-URL: #4810
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Jeremy Whitlock <jwhitlock@apache.org>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>

The current documentation for writable.write only specifies that the
callback is called "once the data has been fully handled".  It is
ambiguous whether this means "successfully handled" and, if so,
whether the callback is called if the data can not be successfully
handled (i.e. an error occurs).

The ambiguity is not only in the documentation.  The stream class
implementations differ on this point.  stream.Writable invokes the
callback with any errors that occur during parameter checking or
during calls to _write.  However, not all classes return all errors
to _write. zlib.Zlib does pass argument and state errors to the
_write (_transform) callback, but does not pass data errors.
http.OutgoingMessage passes argument type errors and some other types
of errors, but not all.

This inconsistency is behind issue #1746 and, I suspect, other issues
in client code which passes a callback to write.

This commit takes no position on whether the callback error behavior
should changed, but simply attempts to document the current behavior
in a way that is open to changes so that users are not caught by
surprise.

PR-URL: #4810
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Jeremy Whitlock <jwhitlock@apache.org>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>

The current documentation for writable.write only specifies that the
callback is called "once the data has been fully handled".  It is
ambiguous whether this means "successfully handled" and, if so,
whether the callback is called if the data can not be successfully
handled (i.e. an error occurs).

The ambiguity is not only in the documentation.  The stream class
implementations differ on this point.  stream.Writable invokes the
callback with any errors that occur during parameter checking or
during calls to _write.  However, not all classes return all errors
to _write. zlib.Zlib does pass argument and state errors to the
_write (_transform) callback, but does not pass data errors.
http.OutgoingMessage passes argument type errors and some other types
of errors, but not all.

This inconsistency is behind issue #1746 and, I suspect, other issues
in client code which passes a callback to write.

This commit takes no position on whether the callback error behavior
should changed, but simply attempts to document the current behavior
in a way that is open to changes so that users are not caught by
surprise.

PR-URL: #4810
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Jeremy Whitlock <jwhitlock@apache.org>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>

The current documentation for writable.write only specifies that the
callback is called "once the data has been fully handled".  It is
ambiguous whether this means "successfully handled" and, if so,
whether the callback is called if the data can not be successfully
handled (i.e. an error occurs).

The ambiguity is not only in the documentation.  The stream class
implementations differ on this point.  stream.Writable invokes the
callback with any errors that occur during parameter checking or
during calls to _write.  However, not all classes return all errors
to _write. zlib.Zlib does pass argument and state errors to the
_write (_transform) callback, but does not pass data errors.
http.OutgoingMessage passes argument type errors and some other types
of errors, but not all.

This inconsistency is behind issue #1746 and, I suspect, other issues
in client code which passes a callback to write.

This commit takes no position on whether the callback error behavior
should changed, but simply attempts to document the current behavior
in a way that is open to changes so that users are not caught by
surprise.

PR-URL: #4810
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Jeremy Whitlock <jwhitlock@apache.org>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>

The current documentation for writable.write only specifies that the
callback is called "once the data has been fully handled".  It is
ambiguous whether this means "successfully handled" and, if so,
whether the callback is called if the data can not be successfully
handled (i.e. an error occurs).

The ambiguity is not only in the documentation.  The stream class
implementations differ on this point.  stream.Writable invokes the
callback with any errors that occur during parameter checking or
during calls to _write.  However, not all classes return all errors
to _write. zlib.Zlib does pass argument and state errors to the
_write (_transform) callback, but does not pass data errors.
http.OutgoingMessage passes argument type errors and some other types
of errors, but not all.

This inconsistency is behind issue #1746 and, I suspect, other issues
in client code which passes a callback to write.

This commit takes no position on whether the callback error behavior
should changed, but simply attempts to document the current behavior
in a way that is open to changes so that users are not caught by
surprise.

PR-URL: #4810
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Jeremy Whitlock <jwhitlock@apache.org>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>