Re: On the case for exception-based error handling.

--ILuaRSyQpoVaJ1HG
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

2000-08-22-16:40:13 Peter Scott:
> >I'm not sure, but I think Chaim's main point was just that, not
> >that divide-by-zero should be ignored too.
>=20
> Well, it could be made user-selectable, right Bennett?  Do you envisage=
=20
> being able to say
>=20
>          use Fatal qw(Arithmetic IO etc)
>=20
> using classnames that fall out of RFC 80?

I hadn't thought about the current cases where the core throws
exceptions. I agree that Fatal would be a fine linguistic hook for
addressing them, if people thought they should be addressed. I would
suggest that I like Fatal's current meaning, where the arguments, if
they are normal words, are the names of functions to wrap; so if
we're doing categories I would think they'd be named the same way
that other modules (e.g. POSIX.pm) do, with names in lowercase that
begin with ":". So I'd expect instead

	use Fatal qw(:arithmetic :io ...);

> Therefore the default (to get the current behavior) would be that
> some of the classes had Fatality enabled and others didn't?

And if Fatal supported unimport, then the default could be inverted
with

	use Fatal qw(:io ...);
	no  Fatal qw(:arithmetic);

-Bennett

--ILuaRSyQpoVaJ1HG
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.2 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE5qSUBL6KAps40sTYRAvq/AJ9nnkuzURLScYsAWeDNPBT/fLRdbACeLopb
1HYJVhri8URzxGsMYA/KZL4=
=O/fb
-----END PGP SIGNATURE-----

--ILuaRSyQpoVaJ1HG--