>Now, every error is guaranteed to be an object. You can call some method >or check some attribute of it to find out if it was an exception. If >you're checking a system() or `` failure, you use it in numerical >context. If you're checking a builtin failure, you use it in string >context (unless you have some fetish about errno). It's not a fetish. It's for portability and reliability. There is no guarantee of the precise text that strerror() would produce when passed EAGAIN or ENOENT, yet it is these errnos by symbolic name that the syscalls are defined to return. Here's a demo: bsd% perl -MErrno=:POSIX -e 'printf "Got: %s\n", $!=ENODEV' Got: Operation not supported by device redhat% perl -MErrno=:POSIX -e 'printf "Got: %s\n", $!=ENODEV' Got: No such device See the problem? You *can't* just say if (!syscall(...) && $! =~ /not supported/) You *must* say if (!syscall(...) && $! == ENODEV) --tom
- Re: RFC 88: What does catch "Foo" { } do? Tony Olekshy
- Re: RFC 88: What does catch "Foo" { } do? Graham Barr
- Structured exception handling should be a core modul... Tony Olekshy
- Re: Structured exception handling should be a co... Peter Scott
- Re: Structured exception handling should be ... Tony Olekshy
- Re: Structured exception handling should be ... Peter Scott
- Re: Structured exception handling should be ... Tony Olekshy
- Re: Structured exception handling should be ... Peter Scott
- Re: Structured exception handling should be ... Tony Olekshy
- Re: Structured exception handling should be ... Peter Scott
- Re: Structured exception handling should be ... Tom Christiansen
- Re: Structured exception handling should be ... Peter Scott
- Re: Structured exception handling should be ... Bart Lateur
- Re: Structured exception handling should be ... Peter Scott
- Re: Structured exception handling should be ... Tony Olekshy