On Thu, Jun 13, 2013 at 9:41 PM, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote: > * Ricardo Signes <perl.p5p@rjbs.manxome.org> [2013-06-11T18:30:14] >> We should issue a warning when an implicit close results in error. >> autodie.pm can then fatalize that warning. We should also fatalize errors on >> the implicit close of the selected fh at END, to deal with errors during -i, >> for example. > > There has been a lot of discussion about the exact semantics this should have. > > I think what Ruslan described, which was close to what I described, sounds > good. (After all, it's close to what I described.) > > Talk about semantics is cheap. The person who presents a working patch is > likely to win the argument. I've not been following this closely, but I have some quick reactions: (1) I don't understand the point about autodie fatalizing warnings. As I understand it, autodie replaces core functions with ones that check return values. (2) IO::Handle has an empty DESTROY block. Would it be enough to make that attempt a close (if the handle is still open) and warn on error? Since lexical filehandles are just buried IO::File objects, I presume it would get called before the underlying handle gets closed, right? (3) I'd prefer to find a way for those who don't care about close warnings to disable it with "no warning 'close'" at an appropriate place. Per FC's point, there may be issues about which pragma is relevant to scope unwinding, which would have to get sorted out. But I'd rather avoid inventing yet another mechanism for error handling. What we have suck and adding more cruft makes it worse, not better. (4) If we're thinking about turning on or off warningness on a dynamic basis, let's do it like autoflush and other handle-specific properties. Yes, that means using a magic variable and select and all wrapped up in a nice IO::Handle method call. -- David Golden <xdg@xdg.me> Take back your inbox! → http://www.bunchmail.com/ Twitter/IRC: @xdgThread Previous | Thread Next