Yuval Kogman wrote:
On Thu, Oct 06, 2005 at 14:27:30 -0600, Luke Palmer wrote:
On 10/6/05, Yuval Kogman [EMAIL PROTECTED] wrote:
when i can't open a file and $! tells me why i couldn't open, i
can resume with an alternative handle that is supposed to be the
same
On Fri, Oct 07, 2005 at 02:31:12 -0400, Austin Hastings wrote:
Yuval Kogman wrote:
On Thu, Oct 06, 2005 at 14:27:30 -0600, Luke Palmer wrote:
On 10/6/05, Yuval Kogman [EMAIL PROTECTED] wrote:
when i can't open a file and $! tells me why i couldn't open, i
can
On Fri, Oct 07, 2005 at 05:23:55 +0100, Piers Cawley wrote:
Peter Haworth [EMAIL PROTECTED] writes:
On Wed, 5 Oct 2005 19:24:47 +0200, Yuval Kogman wrote:
On Wed, Oct 05, 2005 at 16:57:51 +0100, Peter Haworth wrote:
On Mon, 26 Sep 2005 20:17:05 +0200, TSa wrote:
Piers Cawley wrote:
[EMAIL PROTECTED] wrote:
I'm not bashing your idea, because I think it has uses. But I'll
point out that all of these can be easily accompilshed by writing a
wrapper for open(). That would be the usual way to abstract this kind
of thing.
My take on this: resumable exceptions break
HaloO
Yuval Kogman wrote:
We have:
die: throw immediately
fail: return an unthrown exception, which will be thrown
depending on whether our caller, and their caller - every scope
into which this value propagates - is using fatal.
This is enough for normal
Yuval Kogman wrote:
On Fri, Oct 07, 2005 at 02:31:12 -0400, Austin Hastings wrote:
Yuval Kogman wrote:
Stylistically I would tend to disagree, actually. I think it's cleaner to
use exception handling for this.
Also, this implies that you know that the errors are generated by open.
On Fri, Oct 07, 2005 at 10:28:13 -0400, Austin Hastings wrote:
But the point is that resuming from an exception (or
appearing to) is not bound to implemented with continuations.
What's the point?
Continuations are good for exactly this purpose. Parrot already
supports them. I see absolutely
On Wed, Oct 05, 2005 at 13:00:55 -0600, Luke Palmer wrote:
I don't think it was a how is this possible, but more of a what
business does it have?. And as far as I gathered, they're saying
pretty much what you've been saying, but in a different way. It's
about the continuation boundary; that
On Wed, Oct 05, 2005 at 13:41:37 -0700, Dave Whipp wrote:
Reading this thread, I find myself wondering how a resumable exception
differs
from a dynamically scropted function. Imagine this code:
This is sort of like what I mean, except that there is no
encapsulation breakage, since the
On Wed, 5 Oct 2005 19:24:47 +0200, Yuval Kogman wrote:
On Wed, Oct 05, 2005 at 16:57:51 +0100, Peter Haworth wrote:
On Mon, 26 Sep 2005 20:17:05 +0200, TSa wrote:
Piers Cawley wrote:
Exactly which exception is continued?
The bottommost one. If you want to return to somewhere up its
On Thu, Oct 06, 2005 at 18:11:38 +0100, Peter Haworth wrote:
The highest level exception is the only one a caller has any right to deal
with, but even then it doesn't really know what will happen if it resumes
some random continuation attached to the exception.
But then we gain nothing
On 10/6/05, Yuval Kogman [EMAIL PROTECTED] wrote:
when i can't open a file and $! tells me why i couldn't open, i
can resume with an alternative handle that is supposed to be the
same
when I can't reach a host I ask a user if they want to wait any
On Thu, Oct 06, 2005 at 14:27:30 -0600, Luke Palmer wrote:
On 10/6/05, Yuval Kogman [EMAIL PROTECTED] wrote:
when i can't open a file and $! tells me why i couldn't open, i
can resume with an alternative handle that is supposed to be the
same
when I can't
Peter Haworth [EMAIL PROTECTED] writes:
On Wed, 5 Oct 2005 19:24:47 +0200, Yuval Kogman wrote:
On Wed, Oct 05, 2005 at 16:57:51 +0100, Peter Haworth wrote:
On Mon, 26 Sep 2005 20:17:05 +0200, TSa wrote:
Piers Cawley wrote:
Exactly which exception is continued?
The bottommost one. If
On Mon, 26 Sep 2005 20:17:05 +0200, TSa wrote:
Piers Cawley wrote:
Exactly which exception is continued?
The bottommost one. If you want to return to somewhere up its call
chain, do:
$!.caller(n).continue(42)
Whow, how does a higher level exception catcher *in general* know
what
On Wed, Oct 05, 2005 at 16:57:51 +0100, Peter Haworth wrote:
On Mon, 26 Sep 2005 20:17:05 +0200, TSa wrote:
Piers Cawley wrote:
Exactly which exception is continued?
The bottommost one. If you want to return to somewhere up its call
chain, do:
$!.caller(n).continue(42)
Whow,
On 10/5/05, Yuval Kogman [EMAIL PROTECTED] wrote:
On Wed, Oct 05, 2005 at 16:57:51 +0100, Peter Haworth wrote:
On Mon, 26 Sep 2005 20:17:05 +0200, TSa wrote:
Whow, how does a higher level exception catcher *in general* know
what type it should return and how to construct it? The innocent
Luke Palmer wrote:
Of course, exactly how this public interface is declared is quite undefined.
Reading this thread, I find myself wondering how a resumable exception
differs from a dynamically scropted function. Imagine this code:
sub FileNotWriteable( Str $filename ) {
die can't write
.
Almost. I want exceptions, or exceptuations, to be sufficiently
transparent that I can use (below) some mechanism to infer details of
the problem without having to know too much of the internals below me
(but some, obviously); and I want all except(uat)ions to be potentially
resumable, except
is that it lets us delocalize the
processing, but does _not_ keep the exceptions are violent,
incomprehensible events which wrench us from our placid idyll mentality.
In that regard, exceptuations are resumable gotos.
=Austin
On Sat, Oct 01, 2005 at 05:57:54 -0400, Austin Hastings wrote:
Internally, it may be the same. But with exceptions, it's implemented by
someone other than the victim, and leveraged by all. That's the kind of
abstraction I'm looking for. My problem with the whole notion of Either
errorMessage
TSa [EMAIL PROTECTED] writes:
BTW, I would call *intentional* exceptions terrorism.
So that would be all exceptions then. They all get implemented somewhere, even
the ones that get thrown by builtins.
CATCH Exception { say Why do you hate freedom? }
--
Piers Cawley [EMAIL PROTECTED]
HaloO,
Yuval Kogman wrote:
The try/catch mechanism is not like the haskell way, since it is
purposefully ad-hoc. It serves to fix a case by case basis of out
of bounds values. Haskell forbids out of bound values, but in most
programming languages we have them to make things simpler for the
HaloO Piers,
you wrote:
TSa [EMAIL PROTECTED] writes:
BTW, I would call *intentional* exceptions terrorism.
So that would be all exceptions then. They all get implemented somewhere, even
the ones that get thrown by builtins.
I knew that the statement would emotionalize. Sorry to all who
On Fri, Sep 30, 2005 at 18:02:46 +0200, TSa wrote:
I knew that the statement would emotionalize. Sorry to all who don't
like it an this list. But somehow I found it describes the impression
on the handling side somewhat. And I thought it illustrates that exceptions
shouldn't be considered just
HaloO,
Yuval Kogman wrote:
On Wed, Sep 28, 2005 at 09:49:11 -0700, Larry Wall wrote:
But thinking about optional continuations, another thing occured
to me. It's always bugged me that warnings were something different
from exceptions, and now I think we can unify them, if we say that
Yes,
Hi!
On Thu, Sep 29, 2005 at 10:49:40 +0200, TSa wrote:
BTW, I would call *intentional* exceptions terrorism.
Then I would call terrorism non linear control flow ;-)
In that case Afghanistan might be harboring computer scientists that
really like CPS, and bush is Java ;-)
In lack of a better
I'd like to ammend, and perhaps formalize with some definitions from
my dictionary, which ships with OSX:
error - a mistake... the state or condition of being wrong in
conduct or judgement... technical - a measure of the estimated
difference between the observed or
TSa schreef:
Yes, I'm also all for unifying the concepts. But please
don't let us call it exception. Exception should be a
termination oriented (sub)concept. Some kind of scoped giving
up. [...]
In lack of a better word I use Event and we get
Event::Exception, Event::Control, Event::Warn
TSa wrote:
HaloO,
Yuval Kogman wrote:
On Wed, Sep 28, 2005 at 11:46:37 -0500, Adam D. Lopresto wrote:
The recent thread on Expectuations brought back to mind something
I've been
thinking for a while. In short, I propose that use fatal be on by
default, and
that err be turned into
On Thu, Sep 29, 2005 at 13:52:54 -0400, Austin Hastings wrote:
You already know that err is the low-precedence version of //, right?
What replaces that? I like default or defaults myself,
Yes, he proposed 'dor'.
As I see it err is like this:
sub infix:err ($lhs is delayed, $rhs is
I'd like to add a little more. The context of the original throw
probably knows best whether it's even possible or sensical to
continue, so it should be optional whether the exception contains a
resume continuation. The presence of the continuation signals that
the inner code would *like* to
On Wed, Sep 28, 2005 at 09:49:11 -0700, Larry Wall wrote:
I'd like to add a little more. The context of the original throw
probably knows best whether it's even possible or sensical to
continue, so it should be optional whether the exception contains a
resume continuation. The presence of
And handling user errors in a GUI application is a task for event handling,
*not* exception handling. I agree that both mechanisms share large parts
of the infra-structure supporting them. But I make a strong conceptual
distinction between them.
Which leads to the question, does Perl6 have or
On Tue, Sep 27, 2005 at 07:29:48 +0100, Nigel Hamilton wrote:
And handling user errors in a GUI application is a task for event handling,
*not* exception handling. I agree that both mechanisms share large parts
of the infra-structure supporting them. But I make a strong conceptual
distinction
Nigel Hamilton schreef:
From the point of view of the operating system a program is a nasty
exception to its normal running environment - your whole program is a
kind of big exception!
As if a real OS really likes to run idle most of the time.
;)
Like someone intruding on a conversation
Luke Palmer [EMAIL PROTECTED] writes:
On 9/25/05, Yuval Kogman [EMAIL PROTECTED] wrote:
I propose a new model - each exception has a continuation that
allows it to be unfatalized.
I think we've already talked about something like this. But in the
presence of use fatal, it makes a lot more
HaloO,
Piers Cawley wrote:
Exactly which exception is continued?
The bottommost one. If you want to return to somewhere up its call chain, do:
$!.caller(n).continue(42)
Whow, how does a higher level exception catcher *in general* know
what type it should return and how to construct it.
TSa [EMAIL PROTECTED] writes:
HaloO,
Piers Cawley wrote:
Exactly which exception is continued?
The bottommost one. If you want to return to somewhere up its call chain, do:
$!.caller(n).continue(42)
Whow, how does a higher level exception catcher *in general* know
what type it should
On Mon, Sep 26, 2005 at 17:40:52 +0100, Piers Cawley wrote:
Luke Palmer [EMAIL PROTECTED] writes:
On 9/25/05, Yuval Kogman [EMAIL PROTECTED] wrote:
I propose a new model - each exception has a continuation that
allows it to be unfatalized.
I think we've already talked about something
Hi,
Suppose I'm writing a file browser, with a pane on the left to
display the filesystem hierarchy, and a frame on the right to
preview the file.
Suppose I have a convenience function, preview_file which takes a
path and returns a value that the frame display view knows to
render.
Let's define
In order to support continuable exception generators, here is a
style guide for exception values, and an observation on what
exceptions should support at the language level:
* Exceptions should preserve data
All exceptions should contain as much of the original data that
caused them...
With
On Sun, Sep 25, 2005 at 18:11:22 +0300, Yuval Kogman wrote:
In order to support continuable exception generators, here is a
style guide for exception values, and an observation on what
exceptions should support at the language level:
And more...
* Exception strings are for humans
Humans need
To ease the understanding of exactly how this might work, assume
that perl 6 is really all continuation passing style under the
surface (parrot is ;-).
use fatal;
my $x = do_bar();
do_foo();
sub do_bar {
fail bah;
}
The way CPS works is
On 9/25/05, Yuval Kogman [EMAIL PROTECTED] wrote:
I propose a new model - each exception has a continuation that
allows it to be unfatalized.
I think we've already talked about something like this. But in the
presence of use fatal, it makes a lot more sense.
Something comes to mind:
use
On 9/25/05, Luke Palmer [EMAIL PROTECTED] wrote:
[...]
Exactly which exception is continued?
[...]
Named restarts in Common Lisp appear to try to solve a related
problem, if I'm skimming this thread correctly. :-) (see [1]).
Michael
[1]
On Sun, Sep 25, 2005 at 11:32:54 -0600, Luke Palmer wrote:
Exactly which exception is continued?
...
This comes up again with open(). So it's somewhere in between.
Where?
For the open() example I don't have a solution but I know in what
direction to throw it: the same thing that makes croak
47 matches
Mail list logo
