Re: RFC 63 (v3) Exception handling syntax

At 11:52 PM 8/15/00 -0400, Chaim Frenkel wrote:
> >>>>> "PS" == Peter Scott <[email protected]> writes:
>
> >> Please include the comments about global variables and action at a 
> distance.
>
>PS> I'm sorry, my brain is fried.  Can you spell out for me what you mean in
>PS> this context and I'll put it in.
>
>I am adamant against increasing the number of methods of creating
>action at a distance. (Look at the planed removal of all the $/, etc
>variables. Don't keep adding this type of problem.

Done.

>So please, If you intend to continue with these proposals, add to the
>verbiage, my comments about killing them dead.
>
> >> Oh, no! Are you really suggesting that after
> >>
> >> open (FOO, "nonesuch") or throw "file not found"
> >>
> >> The next statement continues??????
> >>
> >> How in $DIETY's name do you expect to protect code?
>
>PS> I said it wasn't necessarily a good thing :-)  It's in the grand Perl
>PS> tradition of giving you enough rope to hang yourself.  If someone really
>PS> chooses to ignore exceptions, they deserve what they get.  Or maybe,
>PS> they're some kind of wizard who has a good reason in some arcane
>PS> situation.  If you like we could stuff it in a Devel:: module.  But at
>PS> least one person had asked for this IIRC.
>
>That person can't be serious. You can do serioous damage to other
>people's code. THey expect not to continue and it does.
>
>This stuff is just asking for trouble.

It would actually be hard to prevent.  throw() would most easily be 
implemented under RFC 63 as a core function and a method of the Exception 
class; a core function for handling the
         throw $exception

case, and a method for handling the

         throw Exception::IO(args)

case (using indirect object syntax).  If that were so, even without the 
ignore() function, I could just say

         sub Exception::IO::throw { 'do nothing' }

and kill it that way.

I am open to suggestions on whether we should make it impossible for 
someone that determined to shoot themselves in the foot to do so.  My 
feeling is that someone smart may have a good reason for doing it (in their 
own code, not in a module given to others), and someone dumb deserves what 
they get for doing something so blatantly stupid.

--
Peter Scott
Pacific Systems Design Technologies