On Saturday, 18 February 2012 at 22:35:58 UTC, Jonathan M Davis
wrote:
I'd hate to see us have a crippled exception hierarchy just
because some
people mishandle exceptions and simply print out messages on
failure in all
cases. Obviously sometimes that's what you have to do, but
often you can
On 24/02/12 13:47, Regan Heath wrote:
On Thu, 23 Feb 2012 15:13:17 -, James Miller ja...@aatch.net wrote:
On 23 February 2012 05:09, Regan Heath re...@netmail.co.nz wrote:
On Tue, 21 Feb 2012 14:19:17 -, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 2/21/12 5:55 AM,
Le 25/02/2012 14:10, Timon Gehr a écrit :
On 02/21/2012 07:57 PM, deadalnix wrote:
opDispatch is nice, but rather incomplete. It doesn't handle template
methods for example.
It surely does.
struct S{
template opDispatch(string op){
auto opDispatch(T...)(T args){
writeln(op, args);
}
}
}
void
On 02/26/2012 01:12 PM, deadalnix wrote:
Le 25/02/2012 14:10, Timon Gehr a écrit :
On 02/21/2012 07:57 PM, deadalnix wrote:
opDispatch is nice, but rather incomplete. It doesn't handle template
methods for example.
It surely does.
struct S{
template opDispatch(string op){
auto
On 02/24/2012 08:14 PM, Andrei Alexandrescu wrote:
On 2/24/12 1:13 PM, H. S. Teoh wrote:
In my mind, contract code belongs in the function signature, because
they document how the function expects to be called, and what it
guarantees in return. It doesn't seem to make sense to me that contracts
On 2/25/12 7:19 AM, Timon Gehr wrote:
On 02/24/2012 08:14 PM, Andrei Alexandrescu wrote:
On 2/24/12 1:13 PM, H. S. Teoh wrote:
In my mind, contract code belongs in the function signature, because
they document how the function expects to be called, and what it
guarantees in return. It doesn't
On 02/25/2012 09:18 PM, Andrei Alexandrescu wrote:
On 2/25/12 7:19 AM, Timon Gehr wrote:
On 02/24/2012 08:14 PM, Andrei Alexandrescu wrote:
On 2/24/12 1:13 PM, H. S. Teoh wrote:
In my mind, contract code belongs in the function signature, because
they document how the function expects to be
On Thu, 23 Feb 2012 15:13:17 -, James Miller ja...@aatch.net wrote:
On 23 February 2012 05:09, Regan Heath re...@netmail.co.nz wrote:
On Tue, 21 Feb 2012 14:19:17 -, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 2/21/12 5:55 AM, Regan Heath wrote:
On Sun, 19 Feb 2012
On Thu, Feb 23, 2012 at 07:06:02PM -0500, Jonathan M Davis wrote:
On Thursday, February 23, 2012 15:18:27 H. S. Teoh wrote:
On Thu, Feb 23, 2012 at 12:07:40PM -0800, Jonathan M Davis wrote:
In my book, a linked library shares equal status with the main
program, therefore the definition of
On Fri, Feb 24, 2012 at 07:57:13AM -0800, H. S. Teoh wrote:
On Thursday, February 23, 2012 15:18:27 H. S. Teoh wrote:
In my book, a linked library shares equal status with the main
program, therefore the definition of user input still sits at
the internal-to-program and external
On Friday, February 24, 2012 07:57:13 H. S. Teoh wrote:
Actually, I wonder if it makes sense for the compiler to insert
in-contract code in the *caller* instead of the callee. Conceptually
speaking, an in-contract means you have to fulfill these conditions
before calling this function. So why
On Friday, February 24, 2012 08:27:44 H. S. Teoh wrote:
On Fri, Feb 24, 2012 at 07:57:13AM -0800, H. S. Teoh wrote:
On Thursday, February 23, 2012 15:18:27 H. S. Teoh wrote:
In my book, a linked library shares equal status with the main
program, therefore the definition of user input
On Fri, Feb 24, 2012 at 01:46:56PM -0500, Jonathan M Davis wrote:
On Friday, February 24, 2012 07:57:13 H. S. Teoh wrote:
Actually, I wonder if it makes sense for the compiler to insert
in-contract code in the *caller* instead of the callee. Conceptually
speaking, an in-contract means you
On 2/24/12 1:13 PM, H. S. Teoh wrote:
In my mind, contract code belongs in the function signature, because
they document how the function expects to be called, and what it
guarantees in return. It doesn't seem to make sense to me that contracts
would be hidden from the user of the library. Sorta
On Sat, 18 Feb 2012 13:52:05 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
There's a discussion that started in a pull request:
https://github.com/alexrp/phobos/commit/4b87dcf39efeb4ddafe8fe99a0ef9a529c0dcaca
Let's come up with a good doctrine for exception defining and
On Fri, Feb 24, 2012 at 04:38:31PM -0500, Steven Schveighoffer wrote:
[...]
On to my second point. One of the issues I have with Java is that
exceptions are *overused*. For example, EOF should not be an
exception, most files have ends, it's not a very exceptional
situation. If there is an
On Friday, February 24, 2012 16:38:31 Steven Schveighoffer wrote:
On to my second point. One of the issues I have with Java is that
exceptions are *overused*. For example, EOF should not be an exception,
most files have ends, it's not a very exceptional situation. If there is
an intuitive way
On Fri, Feb 24, 2012 at 06:48:47PM -0500, Jonathan M Davis wrote:
[...]
However, Java does have a great exception hierarchy, much of which is
standard. And that's a lot better than having only a handful of
unrelated exceptions, let alone having all exceptions be specific to a
module like we do
On Friday, February 24, 2012 16:18:59 H. S. Teoh wrote:
On Fri, Feb 24, 2012 at 06:48:47PM -0500, Jonathan M Davis wrote:
1. Being able to annotate catch blocks in some manner to enable them
to catch multiple, specific exceptions - either by using some kind of
condition
catch(Ex1 e)
On Fri, Feb 24, 2012 at 07:37:03PM -0500, Jonathan M Davis wrote:
On Friday, February 24, 2012 16:18:59 H. S. Teoh wrote:
On Fri, Feb 24, 2012 at 06:48:47PM -0500, Jonathan M Davis wrote:
[...]
which, as you point out, would have to be done at runtime, or by
doing something similar to
On Thu, Feb 23, 2012 at 04:00:04AM +0100, Juan Manuel Cabo wrote:
[...]
I'm sorry. I went over the top. I apollogize.
I apologize too, for some of the inflammatory things I said in the heat
of the moment in some of my replies to this thread.
..I won't post for a while.
This thread is almost
On 2/21/2012 2:29 PM, Ali Çehreli wrote:
On 02/18/2012 09:09 PM, Jim Hewes wrote:
I think of exception handling as tied to contract programming.
I think your use of the word 'contract' is colliding with the contract
programming feature. What you describe later does not match with the
On Wednesday, February 22, 2012 22:33:47 Jim Hewes wrote:
On 2/21/2012 2:29 PM, Ali Çehreli wrote:
On 02/18/2012 09:09 PM, Jim Hewes wrote:
I think of exception handling as tied to contract programming.
I think your use of the word 'contract' is colliding with the contract
On Thu, Feb 23, 2012 at 02:57:43AM -0800, Jonathan M Davis wrote:
[...]
DbC tends to work better with internal stuff where you control both
the caller and the callee, whereas defensive programming works better
with public APIs. But regardless, which is best to use depends on the
situtation
On 23 February 2012 05:09, Regan Heath re...@netmail.co.nz wrote:
On Tue, 21 Feb 2012 14:19:17 -, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 2/21/12 5:55 AM, Regan Heath wrote:
On Sun, 19 Feb 2012 23:04:59 -, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On Thursday, February 23, 2012 07:47:55 H. S. Teoh wrote:
On Thu, Feb 23, 2012 at 02:57:43AM -0800, Jonathan M Davis wrote:
[...]
DbC tends to work better with internal stuff where you control both
the caller and the callee, whereas defensive programming works better
with public APIs.
On Thu, Feb 23, 2012 at 12:07:40PM -0800, Jonathan M Davis wrote:
On Thursday, February 23, 2012 07:47:55 H. S. Teoh wrote:
[...]
The way I understand it, DbC is used for ensuring *program*
correctness (ensure that program logic does not get itself into a
bad state); defensive programming
On Thursday, February 23, 2012 15:18:27 H. S. Teoh wrote:
On Thu, Feb 23, 2012 at 12:07:40PM -0800, Jonathan M Davis wrote:
In my book, a linked library shares equal status with the main
program, therefore the definition of user input still sits at the
internal-to-program and external
On 2012-02-22 08:33, Jonathan M Davis wrote:
On Wednesday, February 22, 2012 08:22:21 Jacob Carlborg wrote:
Now I'm completely lost. According to what I've read this is thread this
is exactly what you want to do, put the formatting inside the exceptions.
No. He wants to provide a way for an
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
Le 21/02/2012 20:01, H. S. Teoh a écrit :
On Tue, Feb 21, 2012 at 07:57:37PM +0100, deadalnix wrote:
Le 21/02/2012 03:33, Robert Jacques a écrit :
[...]
Aren't __traits and opDispatch fun?
opDispatch is nice, but rather incomplete. It doesn't handle template
methods for example.
Does RTTI
Le 22/02/2012 06:47, H. S. Teoh a écrit :
On Tue, Feb 21, 2012 at 07:43:32PM -0500, Jonathan M Davis wrote:
On Tuesday, February 21, 2012 14:15:03 Andrei Alexandrescu wrote:
I thought I was pushing the generics angle, and OO people explained
it to me that that was wrong.
I've changed my
On 2/22/12 1:22 AM, Jacob Carlborg wrote:
Now I'm completely lost. According to what I've read this is thread this
is exactly what you want to do, put the formatting inside the exceptions.
No, just have exceptions inform an external formatter.
Andrei
On Tue, 21 Feb 2012 21:51:34 -0600, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 2/21/12 6:11 PM, Robert Jacques wrote:
On Tue, 21 Feb 2012 09:12:57 -0600, Adam D. Ruppe
destructiona...@gmail.com wrote:
On Tuesday, 21 February 2012 at 02:33:15 UTC, Robert Jacques
wrote:
Nope.
On Tue, Feb 21, 2012 at 6:32 PM, deadalnix deadal...@gmail.com wrote:
Le 21/02/2012 00:23, Andrei Alexandrescu a écrit :
On 2/20/12 4:44 PM, Juan Manuel Cabo wrote:
HAhaha, it sometimes feel as though people are afraid that the
Variant[string]
idea is to never use plain old variables and
On Wed, Feb 22, 2012 at 11:18:13AM +0100, deadalnix wrote:
Le 21/02/2012 20:01, H. S. Teoh a écrit :
[...]
Does RTTI handle template methods?
I'm not aware of any language that have both template and RTTI. So I'm
clueless about this.
Doesn't C++ have RTTI?
T
--
The number you have
Le 22/02/2012 16:33, H. S. Teoh a écrit :
On Wed, Feb 22, 2012 at 11:18:13AM +0100, deadalnix wrote:
Le 21/02/2012 20:01, H. S. Teoh a écrit :
[...]
Does RTTI handle template methods?
I'm not aware of any language that have both template and RTTI. So I'm
clueless about this.
Doesn't C++
On Tue, 21 Feb 2012 14:19:17 -, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 2/21/12 5:55 AM, Regan Heath wrote:
On Sun, 19 Feb 2012 23:04:59 -, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 2/19/12 4:00 PM, Nick Sabalausky wrote:
Seriously, how is
On Wednesday, February 22, 2012 08:19:38 Robert Jacques wrote:
To Variant? Yes, definitely. To Appender? I don't think so. There is an
slight change in API behavior necessitated by performance considerations,
but I don't think it warrants a review by the community at large.
Specifically,
On Wed, Feb 22, 2012 at 11:53:39AM +0100, deadalnix wrote:
[...]
Additionnaly, I would mention that the transient isn't a caracteristic
of the Exception, but of the recovery strategy.
Technically correct. Though I'm playing with the idea of making recovery
strategies a property of an exception
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 Wed, 22 Feb 2012 11:33:57 -0600, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Wednesday, February 22, 2012 08:19:38 Robert Jacques wrote:
To Variant? Yes, definitely. To Appender? I don't think so. There is an
slight change in API behavior necessitated by performance
considerations,
On Wednesday, February 22, 2012 12:16:43 Robert Jacques wrote:
There's a big difference between sealed and not accessible. .data's API
requires exposing an array, and there's no way to do this without leaking
memory like a sieve in one way or another. However, if all you need is to
iterate the
On 2012-02-22 15:01, Andrei Alexandrescu wrote:
On 2/22/12 1:22 AM, Jacob Carlborg wrote:
Now I'm completely lost. According to what I've read this is thread this
is exactly what you want to do, put the formatting inside the exceptions.
No, just have exceptions inform an external formatter.
On Wednesday, February 22, 2012 14:12:07 Jonathan M Davis wrote:
On Wednesday, February 22, 2012 12:16:43 Robert Jacques wrote:
There's a big difference between sealed and not accessible. .data's API
requires exposing an array, and there's no way to do this without leaking
memory like a
On Wed, 22 Feb 2012 13:12:07 -0600, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Wednesday, February 22, 2012 12:16:43 Robert Jacques wrote:
There's a big difference between sealed and not accessible. .data's API
requires exposing an array, and there's no way to do this without
leaking
Le 22/02/2012 18:50, H. S. Teoh a écrit :
On Wed, Feb 22, 2012 at 11:53:39AM +0100, deadalnix wrote:
[...]
Additionnaly, I would mention that the transient isn't a caracteristic
of the Exception, but of the recovery strategy.
Technically correct. Though I'm playing with the idea of making
On Wednesday, February 22, 2012 14:24:49 Robert Jacques wrote:
I view appender's purpose as array building, which is slightly different
from simply speeding up array appending. Simply put, an array is a
terrible data structure for building arrays. But, I can appreciate the
need for mutation
On Wed, 22 Feb 2012 14:17:09 -0600, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Wednesday, February 22, 2012 14:12:07 Jonathan M Davis wrote:
On Wednesday, February 22, 2012 12:16:43 Robert Jacques wrote:
There's a big difference between sealed and not accessible. .data's
API
requires
No, because the array doesn't actually exist until appender
makes copy.
Will one be able to use the sort!()() algorithm directly on your
appender,
that is, without accessing/creating the underlying array?
--jm
On Wednesday, 22 February 2012 at 20:59:15 UTC, Jonathan M Davis
wrote:
speed [...] is really its whole point of existance. I don't
know why else you'd ever use appender.
[...]
- Jonathan M Davis
A use case is to give identity to a built-in array.
Consider this:
class MyClass {
(And not talking about some cheesy insertion sort!!)
If you build an array once and for all, and all you want
is to do binary search on it later, it doesn't make sense to
allocate that big contiguous .data. I'd rather leave it
as an appender.
--jm
On Wednesday, 22 February 2012 at 23:22:35
On Thursday, February 23, 2012 01:38:05 Juan Manuel Cabo wrote:
(And not talking about some cheesy insertion sort!!)
If you build an array once and for all, and all you want
is to do binary search on it later, it doesn't make sense to
allocate that big contiguous .data. I'd rather leave it
On Wed, Feb 22, 2012 at 07:51:27PM -0500, Jonathan M Davis wrote:
[...]
P.S. Please don't top post. Replies should go _after_ the preceding message.
Answer: Because it breaks the normal flow of conversation.
Question: Why is it bad to top-post?
T
--
Why waste time learning, when ignorance
On Wed, 22 Feb 2012 18:51:27 -0600, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Thursday, February 23, 2012 01:38:05 Juan Manuel Cabo wrote:
(And not talking about some cheesy insertion sort!!)
If you build an array once and for all, and all you want
is to do binary search on it later, it
On Thursday, 23 February 2012 at 00:51:38 UTC, Jonathan M Davis
wrote:
[...]
If appender ends up with multiple arrays in it, then random
access is no longer O(1) and is therefore unacceptable. As
such, most sort algorithms wouldn't work with it.
If all I want is binary search on a big
On Thursday, 23 February 2012 at 01:36:32 UTC, Juan Manuel Cabo
wrote:
If all I want is binary search on a big appender, then it
is O(k * n * log(n)), and that k right there doesn't
bother me.
(Where binary search is of course O(log(n))
and accessing individual elements with the proposed
On Thursday, 23 February 2012 at 00:51:38 UTC, Jonathan M Davis
wrote:
P.S. Please don't top post. Replies should go _after_ the
preceding message.
P.S: You are right though, that it wouldn't be O(1) anymore
and it should be said big in the documentation that it is
amortized.
--jm
On Thursday, February 23, 2012 02:36:31 Juan Manuel Cabo wrote:
Yeah, but I don't care about the underlying array. I care
about multiple places referencing the same Appender. If I
from any place that references it, it appends to the same
appender. The Appender array has identity. Ranges do
On Thursday, 23 February 2012 at 01:36:32 UTC, Juan Manuel Cabo
wrote:
On Thursday, 23 February 2012 at 00:51:38 UTC, Jonathan M Davis
wrote:
[...]
If appender ends up with multiple arrays in it, then random
access is no longer O(1) and is therefore unacceptable. As
such, most sort algorithms
On Wed, 22 Feb 2012 19:57:37 -0600, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Thursday, February 23, 2012 02:36:31 Juan Manuel Cabo wrote:
Yeah, but I don't care about the underlying array. I care
about multiple places referencing the same Appender. If I
from any place that references
On Thursday, 23 February 2012 at 01:57:49 UTC, Jonathan M Davis
wrote:
The D equivalent would really be Array, not Appender.
Array!T in D is ref counted and more geared towards T being a
struct. And I had big trouble sorting it with sort!()() in D2.056,
so I made my own sort just to be able to
On Wednesday, February 22, 2012 20:07:37 Robert Jacques wrote:
StringBuilder in .Net is implemented using lists and doesn't expose
iteration nor indexing; why are we worrying about the indexing and
container performance of D's appender?l
Because we're losing something that we currently have
On Thursday, 23 February 2012 at 02:12:20 UTC, Juan Manuel Cabo
wrote:
If we are going to get ideallistic [..]
I'm sorry. I went over the top. I apollogize.
..I won't post for a while.
This thread is almost poping a vein in my neck..
Passion can do that!
I love D. Love all your good work
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
On 2012-02-20 21:25, Nick Sabalausky wrote:
H. S. Teohhst...@quickfur.ath.cx wrote in message
news:mailman.704.1329767254.20196.digitalmar...@puremagic.com...
On Mon, Feb 20, 2012 at 08:36:56PM +0100, Andrej Mitrovic wrote:
On 2/20/12, Juan Manuel Cabojuanmanuel.c...@gmail.com wrote:
will
Am 20.02.2012 22:11, schrieb Juan Manuel Cabo:
Yeah.. that is a problem! :-) Thanks for liking the idea, now we can
talk about the fine details!!
One way is to not let the user direct access to the associative array,
but wrap the e.info[MyDetail] call in a nothrow function, such as
On 2/20/12, H. S. Teoh hst...@quickfur.ath.cx wrote:
Actually, even that isn't ideal. How is the translator to know what on
earth {0} and {1} are?
Sorry, I didn't mean this in the concept of exceptions but generally
when calling writefln format. This exceptions thread has exploded so
fast I
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
On 2012-02-21 01:51, H. S. Teoh wrote:
On Mon, Feb 20, 2012 at 06:19:32PM -0600, Andrei Alexandrescu wrote:
On 2/20/12 5:46 PM, Nick Sabalausky wrote:
[...]
You've suggested adding Variant[string] info to Exception for the
sake of i18n. I think that's what he's referring to. You *could*
argue
Le 20/02/2012 21:57, Andrei Alexandrescu a écrit :
On 2/20/12 1:45 PM, Jonathan M Davis wrote:
On Monday, February 20, 2012 20:42:28 deadalnix wrote:
Le 20/02/2012 20:27, Jonathan M Davis a écrit :
On Monday, February 20, 2012 11:15:08 H. S. Teoh wrote:
That's why I proposed to use runtime
On Saturday, 18 February 2012 at 18:52:05 UTC, Andrei
Alexandrescu wrote:
From experience I humbly submit that catching by type is most
of the time useless.
Completely disagree. Types allow to control place for catch.
Say, some deeply nested function catches its own exceptions,
while outer
On Tuesday, 21 February 2012 at 02:23:58 UTC, Andrei Alexandrescu
wrote:
On 2/20/12 7:02 PM, Juan Manuel Cabo wrote:
oops, sorry!! I just saw a post by someone named Jose. My
thousand apollogies!!
I got confused. It was your argument I meant to refer to -
adding info to the exception in
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
Le 21/02/2012 11:40, Vincent a écrit :
On Saturday, 18 February 2012 at 18:52:05 UTC, Andrei Alexandrescu wrote:
From experience I humbly submit that catching by type is most of the
time useless.
Completely disagree. Types allow to control place for catch. Say, some
deeply nested function
On 2012-02-21 03:34, Andrei Alexandrescu wrote:
On 2/20/12 6:51 PM, H. S. Teoh wrote:
On Mon, Feb 20, 2012 at 06:19:32PM -0600, Andrei Alexandrescu wrote:
On 2/20/12 5:46 PM, Nick Sabalausky wrote:
[...]
You've suggested adding Variant[string] info to Exception for the
sake of i18n. I think
On Sun, 19 Feb 2012 23:04:59 -, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 2/19/12 4:00 PM, Nick Sabalausky wrote:
Seriously, how is this not *already* crystal-clear? I feel as if every
few
weeks you're just coming up with deliberately random shit to argue so
the
On 2012-02-20 23:44, Juan Manuel Cabo wrote:
I still don't like the idea of using Variant[string], though.
(1) It doesn't allow compile-time type checking. This is a big minus, in
my book.
When you need compile-time type checking, define a variable in your class.
Just make sure that you are
On Mon, 20 Feb 2012 21:08:07 -0600, H. S. Teoh hst...@quickfur.ath.cx wrote:
On Mon, Feb 20, 2012 at 08:41:47PM -0600, Andrei Alexandrescu wrote:
On 2/20/12 8:33 PM, Robert Jacques wrote:
Variant e = new MyException();
writeln( e.filename, e.line, e.column);
Aren't __traits and opDispatch
On 2/21/12 4:48 AM, foobar wrote:
On Tuesday, 21 February 2012 at 02:23:58 UTC, Andrei Alexandrescu wrote:
On 2/20/12 7:02 PM, Juan Manuel Cabo wrote:
oops, sorry!! I just saw a post by someone named Jose. My thousand
apollogies!!
I got confused. It was your argument I meant to refer to -
On 2/21/12 4:34 AM, deadalnix wrote:
Le 20/02/2012 21:57, Andrei Alexandrescu a écrit :
class DRoxException : Exception
{
mixin(enableRTTI);
... normal implementation ...
}
Andrei
Why not using std.rtti and generate run time reflection info from
compile time reflexion capability ?
This
On 2/21/12 4:40 AM, Vincent wrote:
On Saturday, 18 February 2012 at 18:52:05 UTC, Andrei Alexandrescu wrote:
From experience I humbly submit that catching by type is most of the
time useless.
Completely disagree. Types allow to control place for catch. Say, some
deeply nested function catches
On 2/21/12 5:11 AM, Jacob Carlborg wrote:
On 2012-02-21 03:34, Andrei Alexandrescu wrote:
I think the correct way of handling this is provide enough information
in the exception so a message can be built where the exception is
caught.
Quite so. I'd add using a unified interface so reusable
On 2/21/12 5:55 AM, Regan Heath wrote:
On Sun, 19 Feb 2012 23:04:59 -, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 2/19/12 4:00 PM, Nick Sabalausky wrote:
Seriously, how is this not *already* crystal-clear? I feel as if
every few
weeks you're just coming up with
On 2/21/12 6:36 AM, Jacob Carlborg wrote:
On 2012-02-20 23:44, Juan Manuel Cabo wrote:
I still don't like the idea of using Variant[string], though.
(1) It doesn't allow compile-time type checking. This is a big minus, in
my book.
When you need compile-time type checking, define a variable
On Tuesday, 21 February 2012 at 14:13:55 UTC, Andrei Alexandrescu
wrote:
On 2/21/12 4:48 AM, foobar wrote:
On Tuesday, 21 February 2012 at 02:23:58 UTC, Andrei
Alexandrescu wrote:
On 2/20/12 7:02 PM, Juan Manuel Cabo wrote:
oops, sorry!! I just saw a post by someone named Jose. My
thousand
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
On 2/21/12 8:38 AM, foobar wrote:
On Tuesday, 21 February 2012 at 14:13:55 UTC, Andrei Alexandrescu wrote:
On 2/21/12 4:48 AM, foobar wrote:
On Tuesday, 21 February 2012 at 02:23:58 UTC, Andrei Alexandrescu wrote:
On 2/20/12 7:02 PM, Juan Manuel Cabo wrote:
oops, sorry!! I just saw a post by
On Tuesday, 21 February 2012 at 02:33:15 UTC, Robert Jacques
wrote:
Nope. See
(https://jshare.johnshopkins.edu/rjacque2/public_html/ )
Any luck in getting the required patches into phobos?
I'd love to see this full thing in there for the next release.
It rox.
This works:
// note: the int parameter above isn't static
dbConn.query(select age from people where id='foobar');
throw new WithErrorCode!FileNotFoundException(
db.rs.getValue(1), file not found);
...
Can you offer a real world use-case where the above isn't sufficient?
What
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
I think he meant to say things have been like that for a while and there's no
blood in the streets.
That's exactly what I meant.
And even if one makes those fields private, anyone can take a pointer
to the class or void[] or whatever and do a mess. (Java isn't exepmpt,
you can do a mess with
On 2012-02-21 15:16, Andrei Alexandrescu wrote:
On 2/21/12 5:11 AM, Jacob Carlborg wrote:
On 2012-02-21 03:34, Andrei Alexandrescu wrote:
I think the correct way of handling this is provide enough information
in the exception so a message can be built where the exception is
caught.
Quite so.
Never mind modifying fields of the exception at some intermediate catch place.
Someone could even catch the exception and not rethrow it.
So: do some trusting. Life gets easier :-)
--jm
On 02/21/2012 12:46 PM, Juan Manuel Cabo wrote:
I think he meant to say things have been like that for a
On Tuesday, 21 February 2012 at 15:38:15 UTC, Juan Manuel Cabo
wrote:
This works:
// note: the int parameter above isn't static
dbConn.query(select age from people where id='foobar');
throw new WithErrorCode!FileNotFoundException(
db.rs.getValue(1), file not found);
...
Can you offer
FileNotFoundException is the super class of the others so the first catch
clause is enough. in fact, the others will
never be called if listed in the above order.
Nice! I missed that. But what if you want to add ErrorCode and Rainbows?
And with your approach, one has to test for type and
Also, you would lose the stacktrace by rethrowing with a different exception
object.
(Currently, the stacktrace is lost by rethrowing the same object, but the
Exception.file
and Exception.line are not lost, and it seems that it is very easy to not lose
the
stacktrace when rethrowing, and it is
On Tuesday, 21 February 2012 at 14:56:52 UTC, Andrei Alexandrescu
wrote:
Can you offer a real world use-case where the above isn't
sufficient?
This has been discussed. A function would want to add
contextual information to an exception and rethrow it.
Requiring a new type for each such
1 - 100 of 572 matches
Mail list logo
