The directory object now has error handling like the rest of the
dart:io. The added tests to some extend overlaps with some of the
tests in DirectpryTest.dart, but I found it better to have error tests
in a single place.
I removed a few type checks sitting in the C++ code for the native
functions as for file we currently don't have them. I have opened
issue 2305 regarding where to do type checks for dart:io native
functions.
R=ager@google.com
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com//9773018
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@5866 260f80e4-7a28-3924-810f-c04153c831b5
Now all both sync and async methods on File and RandomAccessFile
should have correct error handling.
Changed readByte and readByteSync to return -1 instead of
reporting an error when end of file is reached. It seems to make
the most sense.
The amount of boiler-plate code in both the native functions and
native port functions in file.cc is growing. Maybe we should
consider some refactoring, e.g. with a table of the expected
argument types for each native port functions together with known
position of the FILE* argument.
R=ager@google.com
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com//9839053
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@5812 260f80e4-7a28-3924-810f-c04153c831b5
The socket errors and HTTP parser errors are now handled by the
HTTP library and propagated to the related onError callback.
For HttpClient there is no onError on the HttpClient object
itself. Errors on active connections (including connection
errors) are reported on the HttpClientConnection. Errors on
connections sitting in the keep alive pool are handled by just
closing the connection and removing it from the pool. Errors on
the HttpClientConnection are also reported through the onError
callbacks on any active streams.
I am not particulair happy of the way errors are propagated to
the active streams but that can be refactored later.
Added more checks and tests to the HTTP parser.
R=ager@google.com, ajohnsen@google.com
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com//9834008
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@5768 260f80e4-7a28-3924-810f-c04153c831b5
The message content detection and handling should now be more
correct and according to the specification (RFC 2616 section 4.3).
* Requests with no Content-Length and no Transfer-Encoding have no message body
* Responses with status code 1xx, 204 and 304 have no message body
* Responses which are responses to HEAD requests have no message body
Also added support for detecting chunk-extensions and ignoring these.
R=ajohnsen@google.com
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com//9812005
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@5722 260f80e4-7a28-3924-810f-c04153c831b5
Change the streams onError callbacks to get an Exception argument on
all streams.
Added actual error handling to the socket streams.
As it is difficult to determine where an error should be reported I
decided to call all the registered onError callbacks, that is on the
socket itself and on both input and output stream.
Did some additional cleanup of the naming of OnError argument in some tests.
R=ager@google.com
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com//9812007
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@5717 260f80e4-7a28-3924-810f-c04153c831b5
There are currently no tests of the error handling, as it is hard to
create consistent tests. I have done some manual tests locally:
* Lowering the number of file descriptors available (ulimit -n) and hitting that limit
* Running two dart programs communicating and terminating one (using Ctrl-C)
* Running two dart programs communicating on two machines and pulling out the network cable.
If there is an error we always call the onError callback and never the onClosed callback.
On Windows there is the issue that both closing the connection correctly and terminating one end gives the same error (ERROR_NETNAME_DELETED) so both are reported as connection close. Pulling out the network cable gives a different (real) error on Windows though.
On Mac OS it turned out the for kqueue EV_EOF is also used to indicate errors with the error code set in the fflags field. EV_ERROR is only reported if there is an internal error in kevent processing (see http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man2/kqueue.2.html).
R=ager@google.com
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com//9720045
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@5709 260f80e4-7a28-3924-810f-c04153c831b5
Changed the onError callback for sockets to take an exception argument.
First area to report errors for is name resolution.
Changed the IP address resolution from being synchronous with the
creation of the socket to being asynchronous thsough a lookup
service running on a native port. Currently this lookup service
is static on the socket class as we need to call it from a
factory method. We should probably add a separate name lookup
service at some point.
R=ager@google.com
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com//9699017
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@5640 260f80e4-7a28-3924-810f-c04153c831b5
This implements consistent error reporting on all methods on File in dart:io. The async onError method is called with an exception argument which is the same exception as would have been thrown from the corresponding sync method.
The one method on Directory which already did this has been updated as well.
R=ager@google.com
BUG=none
TEST=tests/standalone/src/io/FileTest.dart, tests/standalone/src/io/FileInvalidArgumentsTest.dart
Review URL: https://chromiumcodereview.appspot.com//9630012
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@5396 260f80e4-7a28-3924-810f-c04153c831b5
All output streams now supports writeString which takes the encoding
to be used when transforming the string into a sequence of bytes.
This change also introduces an Encoding interface and Encodings class
as a repository for the supported encodings. Currently this is only
UTF-8, ISO-8859-1 and ASCII. All methods in dart:io which previously
used a String to represent the encoding now uses objects implementing
Encoding.
In this change dart:io is still using the internal UTF-8 encoder used
by the HTTP implementation. I will look into using the one in dart:utf
in a separate change.
R=ager@google.com
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com//9653026
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@5231 260f80e4-7a28-3924-810f-c04153c831b5
rnystrom@google.com