[#3109] Is divmod dangerous? — Dave Thomas <Dave@...>

14 messages 2000/06/06

[#3149] Retrieving the hostname and port in net/http — Roland Jesse <jesse@...>

Hi,

12 messages 2000/06/07

[#3222] Ruby coding standard? — Robert Feldt <feldt@...>

16 messages 2000/06/09

[#3277] Re: BUG or something? — Aleksi Niemel<aleksi.niemela@...>

> |I am new to Ruby and this brings up a question I have had

17 messages 2000/06/12
[#3281] Re: BUG or something? — Dave Thomas <Dave@...> 2000/06/12

Aleksi Niemel<aleksi.niemela@cinnober.com> writes:

[#3296] RE: about documentation — Aleksi Niemel<aleksi.niemela@...>

> I want to contribute to the ruby project in my spare time.

15 messages 2000/06/12

[#3407] Waffling between Python and Ruby — "Warren Postma" <embed@...>

I was looking at the Ruby editor/IDE for windows and was disappointed with

19 messages 2000/06/14

[#3410] Exercice: Translate into Ruby :-) — Jilani Khaldi <jilanik@...>

Hi All,

17 messages 2000/06/14

[#3415] Re: Waffling between Python and Ruby — Andrew Hunt <andy@...>

>Static typing..., hmm,...

11 messages 2000/06/14

[#3453] Re: Static Typing( Was: Waffling between Python and Ruby) — Andrew Hunt <andy@...>

32 messages 2000/06/16

[#3516] Deep copy? — Hugh Sasse Staff Elec Eng <hgs@...>

Given that I cannot overload =, how should I go about ensuring a deep

20 messages 2000/06/19

[#3694] Why it's quiet — hal9000@...

We are all busy learning the new language

26 messages 2000/06/29
[#3703] Re: Why it's quiet — "NAKAMURA, Hiroshi" <nahi@...> 2000/06/30

Hi,

[#3705] Re: Why it's quiet — matz@... (Yukihiro Matsumoto) 2000/06/30

Hi,

[ruby-talk:03063] Re: FailureClass?

From: Quinn Dunkan <quinn@...>
Date: 2000-06-01 06:14:59 UTC
List: ruby-talk #3063
> "Hal E. Fulton" <hfulton@austin.rr.com> writes:
> 
> > This seems like a good idea to me...  Other comments?
> 
> In an abstract sense it sounds like a good idea -- you could
> incorporate reason codes, messages, retry flags and so on in a failure 
> object.
...
>    If the match succeeds, it returns the offset of the start. That's
>    not nil or false, so the expression is true. But if the match
>    fails and the expression returns a failure object, what do we
>    do. Do we build in to the interpreter the fact that failure is
>    false? There mau be some issues there, noy just with performance,
>    but also logically. Alternatively if failure is not false, then

Well, since failure is a fundamental concept common to almost all methods, we
could leave the existing function's return value/type alone and have a
different, special way of returning for failure.  Haskell has a
"Error | OK val" monad, that, with the help of the usual monadic functions,
can be 'lifted' across other function calls so that an error propagates
through the program until it is caught and handled.  ruby doesn't have the
same functionality (oops, pun), so we'd have to build it into the language,
and make it almost a sort of control structure.  It could be generalized to
indicate any exceptional circumstance in addition to errors, and to reflect
that, we could call it

an exception


:)

In This Thread