On 21/11/2011 5:20 PM, Jeff Schultz wrote:
I may not be understanding this correctly, but it seems to have
security implications by breaking encapsulation. The caller-supplied
handler will have access to values at the exception site that the
caller would not normally be able to see.
Couple
On 19/11/2011 2:31 PM, David Rajchenbach-Teller wrote:
Let's switch vocabulary, then. Report and Handle are probably less
loaded with implicit meanings.
Sure. Those are good terms. So long as it's clear there are a few
dimensions to the issue:
- What is checked statically (if at all) for
On Sat, Nov 19, 2011 at 11:41:13AM -0800, Graydon Hoare wrote:
Yes, and I am proposing one: pass *in* your handlers (or symbolic codes
indicating handler-strategy) and have the callee handle *at the site of the
condition*. Sorry if I wasn't clear enough about the implied use of tags I
On 11/18/11 8:45 PM, Graydon Hoare wrote:
Woah woah, I'm arriving late here.
We *have* exceptions. They're called 'failure'. The only point about
them is that you can't catch them. For a couple reasons:
I feel that there is a little misunderstanding. If you do not mind, I
would like to
On 11/19/11 1:45 AM, Niko Matsakis wrote:
A #do[] macro which just returns in the case of failure is basically
equivalent to this in practice, I think.
Niko
Not only that, but it plays better with the strengths of Rust.
Cheers,
David
signature.asc
Description: OpenPGP digital
On 11/19/11 1:56 AM, Niko Matsakis wrote:
On Nov 18, 2011, at 4:51 PM, Niko Matsakis wrote:
1. You know exactly what the failure means and an exact, transparent
recovery mode. For this we recommend simply modeling the recovery
mode you want for expected-but-rare circumstances
On 19/11/2011 4:02 AM, David Rajchenbach-Teller wrote:
Let's start with a little safety vocabulary, not specifically related to
Rust. It is quite common to have two distinct words: exceptions for
exceptional but expected behavior – that you typically want to catch –
Heh. I appreciate the
On 19/11/2011 4:14 AM, David Rajchenbach-Teller wrote:
I can't remember the title of the original exceptions paper, but if I
recall correctly, exceptions were initially designed specifically to
avoid such behaviors, as this quite often leads to messy and unreliable
code.
Exceptions date back
On Sat Nov 19 20:50:48 2011, Graydon Hoare wrote:
Oh, and a simple example where it does not work: you do not want to deal
with scenario user has suddenly removed the USB key smack in the
middle of your code for, say, serializing your data structure to a
compressed output stream for said key.
On 11/19/11 8:41 PM, Graydon Hoare wrote:
On 19/11/2011 4:02 AM, David Rajchenbach-Teller wrote:
Let's start with a little safety vocabulary, not specifically related to
Rust. It is quite common to have two distinct words: exceptions for
exceptional but expected behavior – that you typically
On 18/11/2011 1:12 PM, Jim Peters wrote:
Let's say I have a function parse_file(), it might fail because of I/O
problems or syntax failures, or it may give me back a valid parsed
object. Given that both errors may be detected at any depth in the
internal call tree, in another language
Has anyone considered haskell's monadic errors? As far as the end user
is concerned, it's pretty much equivalent to exceptions, but minus the
stack-jumping-ness of true exceptions. Since at it's heart it's just
returning values of eitherT,U, I would imagine it wouldn't break
typestate:
Graydon Hoare wrote:
To some extent. It depends a lot on the parsing task. I don't mean
to be dismissive. This is a great example. But I want to clarify
things:
- In a Serious Parser, errors are managed explicitly because error
reporting to the user is an Important Diagnostic Feature
On 11/18/2011 01:34 PM, Graydon Hoare wrote:
Sorry to blather on like this, but ... the point of lightweight
tasks in this language is that they're lightweight, and get used
early and often. If everyone's reaction to use a task is oh bother,
those are far too heavy, I think we've made a
A #do[] macro which just returns in the case of failure is basically equivalent
to this in practice, I think.
Niko
On Nov 18, 2011, at 2:18 PM, Erick Tryzelaar wrote:
Has anyone considered haskell's monadic errors? As far as the end user
is concerned, it's pretty much equivalent to
On Nov 18, 2011, at 4:51 PM, Niko Matsakis wrote:
1. You know exactly what the failure means and an exact, transparent
recovery mode. For this we recommend simply modeling the recovery
mode you want for expected-but-rare circumstances as arguments
passed *into* the callee,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu Nov 17 06:10:20 2011, Niko Matsakis wrote:
On Nov 16, 2011, at 11:07 AM, Brian Anderson wrote:
I had thought to redefine result as resultT { ok(T); err(any);
} once that was possible, but I do think maybe creating an exn
type as David
I think this set of macros may be overkill. The #do[] macro alone seems
sufficient to me. Throw is just ret error() and succeed is just ret
success(), after all, both of which are fairly clear and succinct. Catch is
just alt with pattern matching. As for the issues with the error types,
On 11/16/2011 10:58 AM, Niko Matsakis wrote:
I think this set of macros may be overkill. The #do[] macro alone seems sufficient to me. Throw is just ret
error() and succeed is just ret success(), after all, both of which are fairly clear and succinct.
Catch is just alt with pattern
On Nov 16, 2011, at 11:07 AM, Brian Anderson wrote:
I had thought to redefine result as resultT { ok(T); err(any); } once that
was possible, but I do think maybe creating an exn type as David proposed
could be better.
I am somewhat indifferent as to the precise type of exceptions, so long
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue Nov 15 15:30:34 2011, Niko Matsakis wrote:
Yes, I was thinking something similar yesterday. Such a pattern
might well be perfect.
I have just submitted a blocker issue
https://github.com/graydon/rust/issues/1176
Syntax-wise, let's write
21 matches
Mail list logo
