-setting-library/Exception.pod
Log Message:
---
Add StubCode to exceptions
-setting-library/Exception.pod
Log Message:
---
(S32/Exceptions) Add X::Range::InvalidArg exception.
-setting-library/Str.pod
Log Message:
---
force exceptions to lc or uc
-control.pod
Log Message:
---
A couple of fixes to the exceptions spec.
-setting-library/Exception.pod
Log Message:
---
[S32::Exceptions] briefly describe the default exception printer
-operators.pod
Log Message:
---
cmp does not throw exceptions, just fails
Also discuss "mass production" ops that tend to pass failures
through rather than throw them. Which ops are so considered
is of course a matter for ongoing negotiation.
-functions.pod
Log Message:
---
eval() does not catch exceptions
/Exception.pod
Log Message:
---
[S32/Exceptions] add a few syntax errors
/Exception.pod
Log Message:
---
[S32/Exceptions] move %.payload into a separate class, based on feedback by
sorear++
Author: lwall
Date: 2010-07-15 01:53:05 +0200 (Thu, 15 Jul 2010)
New Revision: 31691
Modified:
docs/Perl6/Spec/S04-control.pod
Log:
[S04] more bombastic utterances about not dropping pending exceptions
Modified: docs/Perl6/Spec/S04-control.pod
l unthrown exceptions in the block, does
it throw every one of them? in sequence? autothreading? what happens if
one CATCH handles one of the exception but only an outer CATCH handles
the other?
I'm not sure there is a sane way of having several unthrown exceptions
at the same block, so I think th
Em Qui, 2009-02-26 às 08:55 -0300, Daniel Ruoso escreveu:
> for @! {}
> might provide the needed semantics...
After sending this mail I've just realized I don't know exactly which
are the needed semantics...
what happens if you have several unthrown exceptions in the block, doe
uld be sane to have $! representing the last
exception, so you can still use
my $file = open 'file.txt' or die $!;
no matter how many unthrown exceptions you have in that block.
daniel
On Thu, 26 Feb 2009, Timothy S. Nelson wrote:
My suggested solution would be to change $! to an exception container
object. But then we have to use it in the implicit given in the CATCH block.
If we used an any() Junction, would that do what we want?
Ok, Moritz told me on IRC that this won
also:
: Because the contextual variable C<$!> contains all exceptions collected in
: the current lexical scope...
...that implies to my mind that $! is an exception object, but that an
exception object can contain more than one exception. Is that correct?
But the spec also
On Thu, Feb 26, 2009 at 02:05:28PM +1100, Timothy S. Nelson wrote:
> Does this mean that $! is a container of some sort?
It's an object, which (in the abstract) can contain anything it jolly
well pleases. The main question beyond that is how it responds if
used like one of the standard cont
S04 says:
Because the contextual variable C<$!> contains all exceptions collected in the
current lexical scope, saying C will throw all exceptions,
whether they were handled or not. A bare C/C takes C<$!> as the
default argument.
Does this mean that $! is a conta
HaloO,
Yaakov Belch wrote:
I believe that ---from a usability point of view--- it's very important to:
* classify exceptions by "severity" or other characteristics,
* provide named adverbs/pragmas to modify default CATCH handlers,
* make them configurable by "outer s
Thank you very much!
my $bill =
try ack() orelse
try thpp() orelse
do ppt();
This certainly does what I asked for, and it's short enough (even if we
need to add a few brackets).
Yes, the basic problem with the proposal is that it catches all
exceptions willy nill
ault_value;
compute_statistics($data) // write_log_message("stats failed: $!");
With the proposed change, these ideoms work whether the functions throw
exceptions or not.
You can change the meaning of "fail" to throw exceptions or to return
the unthrown object which is an interesting val
On Wed, Aug 06, 2008 at 09:36:16AM -0700, jerry gay wrote:
: i don't think this will work for perl 6. since perl 6 has resumeable
: exceptions (like C), the meaning of the C operator could be
: ambiguous. given the following statement,
:
: my $bill = ack() // thpp() // ppt();
:
: with per
> in my mind, this strays too far from the meaning of C and adds
> ambiguity that makes the operator unusable. perhaps there's room for
> an operator that gives some sugar for
>
> my $bill = try { ack() CATCH { thpp() } };
>
> but to me that code is concise enough that it doesn't warrant syntacti
On Wed, Aug 6, 2008 at 8:58 AM, Yaakov Belch <[EMAIL PROTECTED]> wrote:
> In a little language that I wrote some time ago, I found it very useful to
> let the // operator catch exceptions:
>
> f(x) // g(y) does:
> * If f(x) returns a defined value, use this value.
> * If f
In a little language that I wrote some time ago, I found it very useful to
let the // operator catch exceptions:
f(x) // g(y) does:
* If f(x) returns a defined value, use this value.
* If f(x) returns an undefined value, use the value of g(x) instead.
* If f(x) throws an exception, catch and keep
,
> the stack is not unwound until some exception handler chooses to
> unwind it by "handling" the exception in question.
Yes, I did. I was grepping specifically for the bit on resumable
exceptions and the quoted bit is 80 lines up so I missed it completely.
Thanks for poin
alls the LEAVE block to release the lock at some later
: date, seems to be far from the best choice. Sure, we can warn
: programmers to make their resumable-exception handlers short, or to only
: throw non-resumable exceptions from blocks that are likely to be called
: in such circumstances. I suppose that
we can warn
programmers to make their resumable-exception handlers short, or to only
throw non-resumable exceptions from blocks that are likely to be called
in such circumstances. I suppose that would be an acceptable resolution,
but it has an aura of non--re-entrant signal handlers about it, so it
On Wed, Oct 04, 2006 at 10:35:05AM -0400, Aaron Sherman wrote:
: Damian Conway wrote:
:
: > @bar».foo if $baz;
:
: That brought to mind the question that I've had for some time: how are
: exceptions going to work on hyper-operators?
:
: Will they kill the hyperoperation in-progr
Aaron Sherman wrote:
Damian Conway wrote:
@bar».foo if $baz;
That brought to mind the question that I've had for some time: how are
exceptions going to work on hyper-operators?
Will they kill the hyperoperation in-progress? e.g. what will $i be:
Corrected example follows (there
Damian Conway wrote:
@bar».foo if $baz;
That brought to mind the question that I've had for some time: how are
exceptions going to work on hyper-operators?
Will they kill the hyperoperation in-progress? e.g. what will $i be:
my $i = 0;
class A { method inci() { d
What is the behaviour of an *uncaught* exception, particularly with
respect to CHECK/END/LEAVE/LAST blocks, destructors, overloading of
the stringify operator on exception objects, the order in which these
things are executed, and the exit code of the process? (And anything
else that I haven't thou
hat we are going to throw exceptions,
there needs to be a quick way of huffmanizing the scaffolding.
IIRC, "use fatal" decides between an exception being thrown and an
"undef but ..." value being returned.
IMO, it's important to coerce code into the same behavior: If
On Wed, 2005-05-11 at 09:50, Luke Palmer wrote:
> Oh, just to avoid further confusion: In the baz() called under fatal,
> it will only turn undefs that were generated by "fail" calls into
> exceptions. Other sorts of undefs will be returned as ordinary
> undefs.
Ok, so let
ns the undef that it got from foo()
Oh, just to avoid further confusion: In the baz() called under fatal,
it will only turn undefs that were generated by "fail" calls into
exceptions. Other sorts of undefs will be returned as ordinary
undefs.
Likewise, in the bar() called under no fatal,
an undef with some helpful diagnostic information (an "unthrown
exception" as Larry has been calling it).
> "use fatal" to make "fail" throw exceptions
>
> A question came up on #perl6 for the following code:
>
> no fatal;
>
Aaron Sherman skribis 2005-05-11 7:44 (-0400):
> "no fatal" to make "fail" just warn
I thought it wouldn't warn, but instead silently return undef (an
unthrown exception).
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.
Given:
"fail" with configurable behavior
"no fatal" to make "fail" just warn
"use fatal" to make "fail" throw exceptions
A question came up on #perl6 for the following code:
no fatal;
class Foo {
;d try and see how this would work. A toy example:
implementing saturated arithetic uses exceptions:
sub incr ( int $a is rw is checked )
{
$a++;
CATCH {
when IntegerOverflow { $a = int.max };
default { throw }
}
}
This would work for a single variable, but no extend it to do a few mor
st first programming. You just write your test and
start the test suite running, when this throws an 'unknown method
exception' or whatever, you use the debugger to implement/stub out the
method in question, retry, and repeat until the test stops throwing
exceptions.
> So, maybe what
This is more of a language thang, so I've redirected your message
there [here].
> The most fundamental feature throwing an exception is that it transfers
> program execution from the call site. Allowing the caller to resume
> execution at that site is a very dangerous form of action at a distance.
idea is golden.
>
>> To change how certain exceptions behave, a block simply changes the methods
>> of the existing ExceptionCreator to point to other subroutines. This
>> approach allows for an ala carte style of exception configuration. Blocks
>> can (through a mod
lse.
While a nifty idea, this is not going to happen, at least not in the
general case. Restartable exceptions are very, very difficult to do.
(And parrot, alas, isn't going to be able to do them) You still need
to establish an exception handler at the spot you want to restart at
(which isn&
esting is that certain common types of
exceptions could be handled in-place, instead of having to write exception
handlers. Perl5 already does some things like this, e.g. undefs become
empty strings and zeros when needed. I'm just suggesting formalizing the
process more so that custom
> From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> Date: Tue, 15 Oct 2002 14:33:28 -0400
I like the idea of this. The finer details, like returning what to
do, could be more elegant. But the extensibility idea is golden.
> To change how certain exceptions behave, a
A brainstorm for your enjoyment, perusal, and general discussion...
SUMMARY
A proposal for an extension to the usual exception handling concept. The
concept detailed here provides a mechanism for handling exceptions in one
of three ways: changing the values being evaluated, setting the result
Me writes:
: "Non-yet-thrown exceptions must be a useful concept."
:
: This is a bullet point from a list in Apo4 introducing
: coverage of exception handling. Was Larry talking
: about an exception object that hasn't yet been thrown?
: Did he refer to this issue again anywhere
"Non-yet-thrown exceptions must be a useful concept."
This is a bullet point from a list in Apo4 introducing
coverage of exception handling. Was Larry talking
about an exception object that hasn't yet been thrown?
Did he refer to this issue again anywhere else in the Apo?
--me
Nicholas Clark wrote:
>
> my $f = open $file or die "can't open $file";
>
> is troublesome. It doesn't report *why* the file can't be opened.
>
> [...] *flexible* exceptions are needed
The first version of RFC 88 didn't care what exception obj
Did we do this one already?
I have an embarrassingly large amount of code that has to do Cisa('Foo') }>, or Ccan('Bar') }> because there is a
chance that C<$foo> is an unblessed reference.
I would use UNIVERSAL::can directly, but I have some code (a
container/decorator class) that messes with is
49 matches
Mail list logo
