Le 22/02/2012 08:32, H. S. Teoh a écrit :
On Tue, Feb 21, 2012 at 08:56:03PM +0100, deadalnix wrote:
Le 21/02/2012 20:00, H. S. Teoh a écrit :
[...]
You're right, that would be unnecessary duplication, especially since
an unhandled Condition becomes a thrown Exception anyway, and it's a
very
On Wed, Feb 22, 2012 at 11:14:11AM +0100, deadalnix wrote:
Le 22/02/2012 08:32, H. S. Teoh a écrit :
[...]
I have an idea. What if handlers took *two* arguments, a Condition,
and a (possibly derived) Exception object? The raise system would
then match conditions to handlers by both the
On Wednesday, 22 February 2012 at 07:30:54 UTC, H. S. Teoh wrote:
I have an idea. What if handlers took *two* arguments, a
Condition, and
a (possibly derived) Exception object? The raise system would
then match
conditions to handlers by both the Condition type and derived
Exception
type.
On Thu, Feb 23, 2012 at 04:37:37AM +0100, Kapps wrote:
[...]
The Condition approach you propose is fairly similar to what I was
thinking of, as an approach to fixing Problems that occur (not
necessarily exceptions). One of the fundamental problems I have with
exceptions is that, despite
All of this heated debate has led me to reconsider our whole concept of
exceptions. It seems that we're squabbling over little details in
existing paradigms. But what of the big picture? What *is* an exception
anyway? We all know the textbook definition, but clearly something is
missing since we
Am 21.02.2012 09:15, schrieb H. S. Teoh:
Sorry for this super-long post
perfect length, helps to clean the brain and focus on the real problems
again
First great post. Don't be sorry, it is insightful. The Condition
catgory make a lot of sense to me.
Le 21/02/2012 09:15, H. S. Teoh a écrit :
Currently, I'm still unsure whether Conditions and Exceptions should be
unified, or they should be kept separate; deadalnix recommended they be
kept
On 02/21/12 09:15, H. S. Teoh wrote:
Sorry for this super-long post, but I wanted to lay my ideas out in a
coherent fashion so that we can discuss its conceptual aspects without
getting lost with arguing about the details. I hope this is a step in
the right direction toward a better model of
Le 21/02/2012 11:55, deadalnix a écrit :
First great post. Don't be sorry, it is insightful. The Condition
catgory make a lot of sense to me.
Le 21/02/2012 09:15, H. S. Teoh a écrit :
Currently, I'm still unsure whether Conditions and Exceptions should be
unified, or they should be kept
On Tue, Feb 21, 2012 at 03:54:30PM +0100, Artur Skawina wrote:
On 02/21/12 09:15, H. S. Teoh wrote:
Sorry for this super-long post, but I wanted to lay my ideas out in a
coherent fashion so that we can discuss its conceptual aspects without
getting lost with arguing about the details. I
Le 21/02/2012 17:56, H. S. Teoh a écrit :
The only thing I added, perhaps, is that instead of problem-specific
conditions, as they appear to have in Lisp, I'm looking at generic
categories of conditions, that you can handle from high-level code
without ever needing to know the specifics of
On Tue, Feb 21, 2012 at 06:01:09PM +0100, deadalnix wrote:
Le 21/02/2012 17:56, H. S. Teoh a écrit :
The only thing I added, perhaps, is that instead of problem-specific
conditions, as they appear to have in Lisp, I'm looking at generic
categories of conditions, that you can handle from
Le 21/02/2012 18:10, H. S. Teoh a écrit :
On Tue, Feb 21, 2012 at 06:01:09PM +0100, deadalnix wrote:
Le 21/02/2012 17:56, H. S. Teoh a écrit :
The only thing I added, perhaps, is that instead of problem-specific
conditions, as they appear to have in Lisp, I'm looking at generic
categories of
On 02/21/12 17:56, H. S. Teoh wrote:
On Tue, Feb 21, 2012 at 03:54:30PM +0100, Artur Skawina wrote:
On 02/21/12 09:15, H. S. Teoh wrote:
The try-catch mechanism is not adequate to implement all the
recovery actions described above. As I've said before when
discussing what I
Imagine that
On Tue, Feb 21, 2012 at 06:24:01PM +0100, deadalnix wrote:
Le 21/02/2012 18:10, H. S. Teoh a écrit :
[...]
True, and there's nothing to stop you from digging into the details
of the raised Condition if you want to. I did consider implementing
Conditions as some kind of class hierarchy, so that
On Tuesday, February 21, 2012 00:15:48 H. S. Teoh wrote:
TRANSITIVITY
I still contend that this useless, because you need to know what went wrong to
know whether you actually want to retry anything. And just because the
particular operation that threw could be retried again doesn't mean that
Le 21/02/2012 20:00, H. S. Teoh a écrit :
On Tue, Feb 21, 2012 at 06:24:01PM +0100, deadalnix wrote:
Le 21/02/2012 18:10, H. S. Teoh a écrit :
[...]
True, and there's nothing to stop you from digging into the details
of the raised Condition if you want to. I did consider implementing
On 2012-02-21 09:15, H. S. Teoh wrote:
All of this heated debate has led me to reconsider our whole concept of
exceptions. It seems that we're squabbling over little details in
existing paradigms. But what of the big picture? What *is* an exception
anyway? We all know the textbook definition,
On Tue, Feb 21, 2012 at 02:40:30PM -0500, Jonathan M Davis wrote:
On Tuesday, February 21, 2012 00:15:48 H. S. Teoh wrote:
TRANSITIVITY
I still contend that this useless, because you need to know what went wrong
to
know whether you actually want to retry anything. And just because the
On Tue, Feb 21, 2012 at 07:15:29PM +0100, Artur Skawina wrote:
On 02/21/12 17:56, H. S. Teoh wrote:
[...]
I don't think something like this can reliably work - handling unknown
error conditions in code not expecting them is not a good idea.
I'm not proposing we do this for *every* error. Only
On Tue, Feb 21, 2012 at 08:56:03PM +0100, deadalnix wrote:
Le 21/02/2012 20:00, H. S. Teoh a écrit :
[...]
You're right, that would be unnecessary duplication, especially since
an unhandled Condition becomes a thrown Exception anyway, and it's a
very bad idea to duplicate the entire Exception
21 matches
Mail list logo
