1. posterid:342571
  2. Messages

Re: "broken pipe", but not when debugging...

Jack Brindle
 

Jens;
Thank you for the opportunity to expound on this. See below…

On Aug 11, 2017, at 9:48 AM, Jens Alfke <jens@...> wrote:


On Aug 10, 2017, at 9:30 PM, Graham Cox <graham@...> wrote:

I can’t find any mention of functions called signal() or ioctl() in the current (Xcode 8) documentation browser. But then, it seems we’ve lost the ability to view man pages. WTF, why are we going backwards with every “update”?

It does seem absurd that the most fundamental APIs — the C standard library and POSIX/Darwin system calls — aren’t supported by Xcode’s documentation features. Especially since the header files give zero information, usually not even parameter names. I assume this is something hundreds of people have already filed bug reports about over the years. 

I just end up typing “man foo” in a Terminal window, or using the awesome Dash app.


Jack Brindle wrote:

Be sure and put the data write into a try-catch block in order
to catch the broken pipe (assuming it occurs on a write). This is actually documented, but I’ll have to go find it to say. My notes indicate the
docs to say: This method raises an exception if the file descriptor is closed or is not valid, if the receiver represents an unconnected pipe
or socket endpoint, if no free space is left on the file system, or if any other writing error occurs.

I think this is a separate (but related) issue. NSTask is one of the few Cocoa APIs that will throw exceptions in ‘normal’ use to indicate a runtime error, so your advice is correct. But the SIGPIPE crash is different — signals are not exceptions, they’re an earlier lower-level mechanism.

A look at the discussion for NSFileHandle’s writeData: method provides the following:
"This method raises an exception if the file descriptor is closed or is not valid, if the receiver represents an unconnected pipe or socket endpoint, if no free space is left on the file system, or if any other writing error occurs.”

The exception is caused directly by the broken pipe. The exception handler is picking it up so that a try-catch block can directly handle and correct for it. The same text is in the availableData method. I tend to be very defensive in my code, especially in areas where
external forces can cause problems. This is one such area. After I started using try-catch blocks around these methods the crash issues disappeared.

I believe there are many other issues that the Cocoa frameworks handle with exceptions that we used to handle otherwise - that is with signal handling. I still have some signal handling code, but for the most part it has mostly gone away as we move more into the
try-catch exception handling world. Perhaps this is why it is more difficult to find docs for this things. Having said that, ioctl is so important that it must be available.

In any case, learning to use try-catch has been very beneficial!

- Jack


—Jens
Join {cocoa@apple-dev.groups.io to automatically receive all group messages.