Andrei Alexandrescu wrote:
> On 6/11/13 3:09 AM, Jacob Carlborg wrote:
>> On 2013-06-11 08:38, Nick Sabalausky wrote:
>>
>>> I just tried both on Debian 6:
>>>
>>> nick@debian6:~$ cat 1< /dev/null
>>> cfws
>>> cat: write error: Bad file descriptor
>>> nick@debian6:~$ echo meh 1< /dev/null
>>> bash: echo: write error: Bad file descriptor
>>>
>>> Maybe OSX behaves differently?
>> I get the same on Mac OS X 10.6.3 using bash. Is Andrei perhaps using another shell?
> 
> I use zsh. Indeed under bash I can reproduce the failure. But if I run the printf-based test, it exits successfully.
> 
	Note that for zsh, "echo" is a builtin command, whereas bash calls
the /usr/bin/echo executable...

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

On 6/11/2013 11:38 AM, Andrei Alexandrescu wrote:
> On 6/11/13 1:01 PM, Lars T. Kyllingstad wrote:
>> On Tuesday, 11 June 2013 at 16:50:50 UTC, Andrei Alexandrescu wrote:
>>> On 6/11/13 11:57 AM, Steven Schveighoffer wrote:
>>>> This code DOES fail:
>>>>
>>>> import std.stdio;
>>>>
>>>> int main()
>>>> {
>>>> writeln("hello");
>>>> std.stdio.stdout.flush();
>>>> return 0;
>>>> }
>>>
>>> Ah, I suspected so. (At a point in D's history writeln() did do a
>>> flush; people wanted to eliminate it for efficiency reasons.)
>>>
>>> We could introduce a flush() with throw in std.stdiobase.
>>
>> As in a module destructor? Isn't it better to let the error pass
>> silently rather than throwing an exception that can't be caught?
>
> It will not be caught but will cause the entire program to print a diagnostic
> and exit with a nonzero error code, which is useful.

The flush should be in the termination code (not in writeln), where it should throw.

On Tue, 11 Jun 2013 14:44:17 -0400, Jérôme M. Berger <jeberger@free.fr> wrote:

> Andrei Alexandrescu wrote:
>> On 6/11/13 3:09 AM, Jacob Carlborg wrote:
>>> On 2013-06-11 08:38, Nick Sabalausky wrote:
>>>
>>>> I just tried both on Debian 6:
>>>>
>>>> nick@debian6:~$ cat 1< /dev/null
>>>> cfws
>>>> cat: write error: Bad file descriptor
>>>> nick@debian6:~$ echo meh 1< /dev/null
>>>> bash: echo: write error: Bad file descriptor
>>>>
>>>> Maybe OSX behaves differently?
>>> I get the same on Mac OS X 10.6.3 using bash. Is Andrei perhaps using
>>> another shell?
>>
>> I use zsh. Indeed under bash I can reproduce the failure. But if I run
>> the printf-based test, it exits successfully.
>>
> 	Note that for zsh, "echo" is a builtin command, whereas bash calls
> the /usr/bin/echo executable...

This is so not true :)

Stevens-MacBook-Pro:testd steves$ echo $SHELL
/bin/bash
Stevens-MacBook-Pro:testd steves$ type echo
echo is a shell builtin

echo has been a shell builtin since bourne shell (/bin/sh)

But your point is a good one, built-in commands very much will behave differently than separate programs.  For one, echo has to clean up after itself since it doesn't spawn a new process.

-Steve

On Tue, 11 Jun 2013 14:38:51 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 6/11/13 1:01 PM, Lars T. Kyllingstad wrote:
>> As in a module destructor? Isn't it better to let the error pass
>> silently rather than throwing an exception that can't be caught?
>
> It will not be caught but will cause the entire program to print a diagnostic and exit with a nonzero error code, which is useful.

How exactly is this useful?  What if you returned a different error code and you prefer that to come through?

Also note, if stderr isn't working, "printing" anything diagnostic will be gone (I wonder what happens in that case?)

-Steve

On Tuesday, 11 June 2013 at 18:38:51 UTC, Andrei Alexandrescu wrote:
> On 6/11/13 1:01 PM, Lars T. Kyllingstad wrote:
>> As in a module destructor? Isn't it better to let the error pass
>> silently rather than throwing an exception that can't be caught?
>
> It will not be caught but will cause the entire program to print a diagnostic and exit with a nonzero error code, which is useful.

Then we should also provide a hook so the user has the option of handling it.  For example, core.exception could provide

  void setStaticDestructorExceptionHandler(
      void function(string module, Throwable t) handler);

or similar.

On Tuesday, 11 June 2013 at 16:50:50 UTC, Andrei Alexandrescu wrote:
> On 6/11/13 11:57 AM, Steven Schveighoffer wrote:
>> This code DOES fail:
>>
>> import std.stdio;
>>
>> int main()
>> {
>> writeln("hello");
>> std.stdio.stdout.flush();
>> return 0;
>> }
>
> Ah, I suspected so. (At a point in D's history writeln() did do a flush; people wanted to eliminate it for efficiency reasons.)
>
> We could introduce a flush() with throw in std.stdiobase.
>
>
> Andrei

The best solution would be for writeln() to throw on use, and I think it's fairly easy to implement: just flush once after using the file descriptor for the first time, and throw if it fails.

While it doesn't cover a case where file descriptor becomes non-writable during the program lifetime, it covers the most common case of file descriptor not being writable at all.

On 6/11/13 3:25 PM, Steven Schveighoffer wrote:
> On Tue, 11 Jun 2013 14:38:51 -0400, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>
>> On 6/11/13 1:01 PM, Lars T. Kyllingstad wrote:
>>> As in a module destructor? Isn't it better to let the error pass
>>> silently rather than throwing an exception that can't be caught?
>>
>> It will not be caught but will cause the entire program to print a
>> diagnostic and exit with a nonzero error code, which is useful.
>
> How exactly is this useful? What if you returned a different error code
> and you prefer that to come through?

I think that can be very useful.

Andrei

On 6/11/13 3:36 PM, Lars T. Kyllingstad wrote:
> On Tuesday, 11 June 2013 at 18:38:51 UTC, Andrei Alexandrescu wrote:
>> On 6/11/13 1:01 PM, Lars T. Kyllingstad wrote:
>>> As in a module destructor? Isn't it better to let the error pass
>>> silently rather than throwing an exception that can't be caught?
>>
>> It will not be caught but will cause the entire program to print a
>> diagnostic and exit with a nonzero error code, which is useful.
>
> Then we should also provide a hook so the user has the option of
> handling it. For example, core.exception could provide
>
> void setStaticDestructorExceptionHandler(
> void function(string module, Throwable t) handler);
>
> or similar.

That's nice but but seems overdesign. I'd say let's fix the bug for now.

Andrei

On 6/11/2013 12:25 PM, Steven Schveighoffer wrote:
> On Tue, 11 Jun 2013 14:38:51 -0400, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>
>> On 6/11/13 1:01 PM, Lars T. Kyllingstad wrote:
>>> As in a module destructor? Isn't it better to let the error pass
>>> silently rather than throwing an exception that can't be caught?
>>
>> It will not be caught but will cause the entire program to print a diagnostic
>> and exit with a nonzero error code, which is useful.
>
> How exactly is this useful?

I used to entertain myself and friends by setting up unix so the disk is nearly full, and then trying various commands that produced output, and sending the output to the disk.

Because so many C programs fail to check for failed output, all kinds of entertaining random things would happen.

On Tue, 11 Jun 2013 16:42:43 -0700
Walter Bright <newshound2@digitalmars.com> wrote:
> 
> I used to entertain myself and friends by setting up unix so the disk is nearly full, and then trying various commands that produced output, and sending the output to the disk.
> 
> Because so many C programs fail to check for failed output, all kinds of entertaining random things would happen.
> 

http://xkcd.com/1084/

Unix's design is amazingly powerful, but it's also interesting
how much potential that creates for things to get seriously screwed
up. :)