Re: Structured exception handling should be a core module. by Peter Scott- August 29, 2000 At 01:07 PM 82900 -0600, Tom Christiansen wrote:> >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&39;re checking a system() or failure, you use it in numerical> >context. If you&39;re checking a builtin failure, you use it in string> >context (unless you have some fetish about errno).>>It&39;s not a fetish. It&39;s for portability and reliability. ...http://www.nntp.perl.org/group/perl.perl6.language.errors/2000/08/msg293.html Re: Structured exception handling should be a core module. by Tom Christiansen- August 29, 2000 >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&39;re checking a system() or failure, you use it in numerical >context. If you&39;re checking a builtin failure, you use it in string >context (unless you have some fetish about errno).It&39;s not a fetish. It&39;s for portability and reliability. There isno guarantee of the precise text that strerror() would producewhen passed.http://www.nntp.perl.org/group/perl.perl6.language.errors/2000/08/msg292.html Re: Structured exception handling should be a core module. by Peter Scott- August 29, 2000 At 09:41 PM 82800 -0600, Tony Olekshy wrote:>I just want the cognitive simplicity of knowing that $ and every> isa Exception, no matter what.>>Why not merge $!, $E, and $ into $!, but leave $ alone too>That way, none of the existing dieeval code will break without>being modified to check ref $!.How about this: RFC 151 stands ($! is the only error variable), but it is always an object. Whether it&39;s in the Exception class or not I don&39;t really care (although it isn&39;t...http://www.nntp.perl.org/group/perl.perl6.language.errors/2000/08/msg291.html Re: Structured exception handling should be a core module. by Tony Olekshy- August 28, 2000 Peter Scott wrote:> > Tony Olekshy wrote:> >> > So if open, for example, can set $! without invoking die, then> > $! and $ must not be merged. As I read it, 151 would (as> > currently promulgated) not meet my requirement for the unique> > nature of a $-style variable. I don&39;t think overloading ref to> > pick off true exceptions would make me happy either ;-)> > Actually, think about it some more. Why not If you want to> implement RFC 88.http://www.nntp.perl.org/group/perl.perl6.language.errors/2000/08/msg290.html Re: On the case for exception-based error handling. by Peter Scott- August 28, 2000 At 12:16 PM 82700 -0400, Bennett Todd wrote:> > The ramifications of some of these things are sufficiently> > important that drawing attention to them might be a good thing.> > In this case, note that Perl 6 will need to spell out which core> > exceptions are by default fatal (eg, :arithmetic) and which> > aren&39;t. Although RFC 70 doesn&39;t have to do that.>>It feels to me like this should maybe be divided into some change to>RFC 70, along with a...http://www.nntp.perl.org/group/perl.perl6.language.errors/2000/08/msg289.html Re: Structured exception handling should be a core module. by Peter Scott- August 28, 2000 At 01:42 AM 82500 -0600, Tony Olekshy wrote:>Peter Scott wrote:> > If $ and $! are merged, then in code like> >> > try > > system_call_that_fails();> > more_stuff_that_succeeds();> > > > finally > > > >> > does the finally block think there is a current exception or not> > $! was set by the failed system call, but nothing died or threw.> > If $ is put.http://www.nntp.perl.org/group/perl.perl6.language.errors/2000/08/msg288.html Re: Structured exception handling should be a core module. by Peter Scott- August 28, 2000 At 10:13 AM 82500 +0200, Bart Lateur wrote:>You&39;re citing my objection for merging in $ with the rest of the error>variables. $ currently is the "eval failed" flag, irrespective of what>else failed. We must have such a flag. If $ and $! would be merged,>$! will have to be cleared if the eval doesn&39;t fail, just like $ is>now.Yes. Basically, you can think of the new $! as getting done to it whatever was last done to any of the set of $, $!, $E, and $ in the current.http://www.nntp.perl.org/group/perl.perl6.language.errors/2000/08/msg287.html On RFC 88: Serendipity while throwing a string. by Tony Olekshy- August 28, 2000 I have been working on the Perl 5 reference implementation ofRFC 88 functionality (Try.pm, which is currently available at:http:www.avrasoft.comperl6try6-ref5.txt ), and I stumbledacross the following result.If you are writing some code, and there is a "throw" subroutinein scope, and there is a package Exception in scope and it hasa "throw" subroutine, then Perl 5 can tell the following apart(search for the !throw-3 regression test in try6-ref5.txt): throw "A...http://www.nntp.perl.org/group/perl.perl6.language.errors/2000/08/msg286.html Re: On the case for exception-based error handling. by Bennett Todd- August 27, 2000 2000-08-27-12:03:07 Peter Scott:> > use Fatal qw(:io ...);> > no Fatal qw(:arithmetic);> > Bingo, yes. I will make appropriate changes to RFC 80. You might> think about whether RFC 70 needs to be changed.I don&39;t think so; while I mention styles of changes and growth forFatal.pm, I don&39;t regard that as the focus of RFC 70. RFC 70 merelyproposes that the core be changed so that Fatal.pm can be finished;the discussion of the nature of future growth for.http://www.nntp.perl.org/group/perl.perl6.language.errors/2000/08/msg285.html Re: On the case for exception-based error handling. by Peter Scott- August 27, 2000 At 10:26 AM 82700 -0400, Bennett Todd wrote:>So I&39;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&39;t>>And if Fatal supported unimport, then the default could be inverted>with>> use Fatal qw(:io ...);> no Fatal qw(:arithmetic);Bingo, yes. I will make appropriate changes to RFC 80. You...http://www.nntp.perl.org/group/perl.perl6.language.errors/2000/08/msg284.html |