On 2/19/12 12:54 AM, H. S. Teoh wrote:
On Sun, Feb 19, 2012 at 12:43:58AM -0600, Andrei Alexandrescu wrote:
On 2/18/12 8:00 PM, H. S. Teoh wrote:
From this and other posts I'd say we need to design the base exception
classes better, for example by defining an overridable property
isTransient t
On 2/19/12 12:56 AM, Jonathan M Davis wrote:
I think that being able to have a catch block which took multiple exception
types would be plenty. There are times when it would be very valuable to be
able to use the same catch block for multiple exceptions without having to
catch their base type (wh
"Jonathan M Davis" wrote in message
news:mailman.585.1329637995.20196.digitalmar...@puremagic.com...
> On Sunday, February 19, 2012 18:44:30 Daniel Murphy wrote:
>> I assume you mean the _first_ catch block?
>
> Yes. I should have been more specific.
>
>> By the looks of it java 7 has this with a
On 2/19/12 1:12 AM, Jonathan M Davis wrote:
On Sunday, February 19, 2012 00:43:58 Andrei Alexandrescu wrote:
On 2/18/12 8:00 PM, H. S. Teoh wrote:
From this and other posts I'd say we need to design the base exception
classes better, for example by defining an overridable property
isTransie
On Sun, Feb 19, 2012 at 01:05:25AM -0600, Andrei Alexandrescu wrote:
[...]
> Ideally we'd have the right number of types - not more, not less. The
> main purpose of this thread is to figure how many exception types are
> "just right". There has been a tendency in Phobos to just add a
> module-spec
On Sat, Feb 18, 2012 at 11:52:00PM -0800, Jonathan M Davis wrote:
[...]
> So, while at first glance, it seems like a good idea, I think that it
> has too many issues as-is to work. It might be possible to adjust the
> idea to make it workable though. Right now, it's possible to do it via
> mixins o
On Sun, Feb 19, 2012 at 02:04:50AM -0600, Andrei Alexandrescu wrote:
> On 2/19/12 12:56 AM, Jonathan M Davis wrote:
> >I think that being able to have a catch block which took multiple
> >exception types would be plenty. There are times when it would be
> >very valuable to be able to use the same c
The issue here isn't deep vs. flat hierarchy (like the rest of the thread),
it's about improving code clarity/dry.
This is much like the 'case A, B:' syntax (or fallthrough/goto case) in
switches.
Even with a flat hierarchy, you might still want to handle a set of
exceptions deriving from Exce
On Sunday, February 19, 2012 02:04:50 Andrei Alexandrescu wrote:
> On 2/19/12 12:56 AM, Jonathan M Davis wrote:
> > I think that being able to have a catch block which took multiple
> > exception
> > types would be plenty. There are times when it would be very valuable to
> > be
> > able to use the
On Sun, Feb 19, 2012 at 02:02:39AM -0600, Andrei Alexandrescu wrote:
> On 2/19/12 12:54 AM, H. S. Teoh wrote:
> >On Sun, Feb 19, 2012 at 12:43:58AM -0600, Andrei Alexandrescu wrote:
[...]
> >>I'm thinking an error is transient if retrying the operation with
> >>the same exact data may succeed. That
On Sunday, February 19, 2012 02:06:38 Andrei Alexandrescu wrote:
> On 2/19/12 1:12 AM, Jonathan M Davis wrote:
> > On Sunday, February 19, 2012 00:43:58 Andrei Alexandrescu wrote:
> >> On 2/18/12 8:00 PM, H. S. Teoh wrote:
> From this and other posts I'd say we need to design the base
> >>>
On Sunday, February 19, 2012 00:26:57 H. S. Teoh wrote:
> On Sat, Feb 18, 2012 at 11:52:00PM -0800, Jonathan M Davis wrote:
> [...]
>
> > So, while at first glance, it seems like a good idea, I think that it
> > has too many issues as-is to work. It might be possible to adjust the
> > idea to make
On Sunday, February 19, 2012 19:00:20 Daniel Murphy wrote:
> I wasn't really serious about implicit fallthrough.
Lately, it seems like I can never tell whether anyone's being serious or not
online. :)
> Out of the syntaxes I could come up with:
> catch(Ex1, Ex2 e)
> catch(e : Ex1, Ex2)
> catch(E
Hello D community! This is my first post!! I hope I can bring
clarity to all this. If not, I apologize.
Some time ago I researched the best way to classify exceptions
and build a hierarchy. I came up with the following rules:
1) At the top level, there would be RecoverableExceptions and
Fat
Le 19/02/2012 08:05, Andrei Alexandrescu a écrit :
How about a system in which you can say whether an exception is I/O
related, network related, recoverable or not, should be displayed to the
user or not, etc. Such is difficult to represent with inheritance alone.
That may sound great on the p
That proposed syntax is nicer than this, but at least you can do
it this way:
just call the same function from both catch blocks.
#!/usr/bin/rdmd
import std.stdio, std.utf, std.string;
void main() {
void handleStringAndUtf(Exception ex) {
if (typeid(ex).name == "std.utf.U
On Sun, Feb 19, 2012 at 1:31 AM, Nick Sabalausky wrote:
> "H. S. Teoh" wrote in message
> news:mailman.527.1329589896.20196.digitalmar...@puremagic.com...
>> On Sat, Feb 18, 2012 at 12:10:48PM -0500, Nick Sabalausky wrote:
>>
>> [...]
>>> If I'm using a server that doesn't already have ssh set up
Le 19/02/2012 02:23, Jonathan M Davis a écrit :
On Saturday, February 18, 2012 17:20:41 H. S. Teoh wrote:
On Sun, Feb 19, 2012 at 01:10:10AM +, Ben Davis wrote:
[...]
I guess this is a bit off topic, but what you probably want is
syntactic sugar that says "declare constructors matching all
Le 19/02/2012 06:09, Jim Hewes a écrit :
On 2/18/2012 5:59 PM, Robert Jacques wrote:
But you _always_ know what went wrong: An unexpected error occurred
while trying to do X, where X is whatever is inside the try-catch block.
Exceptions are for exceptional situations...
Not to jump on you in p
On 2012-02-18 23:26, Jonathan M Davis wrote:
On Saturday, February 18, 2012 20:20:23 deadalnix wrote:
I think your oppinion here is shaped by C++. For what I experienced, in
C++, exception are only usefull for very important problem you cannot
possibly solve, and at the best log the error and ex
Le 19/02/2012 04:31, Walter Bright a écrit :
On 2/18/2012 3:13 PM, Andrei Alexandrescu wrote:
On 2/18/12 4:26 PM, Jonathan M Davis wrote (abridged):
GetOptException
FlagArgumentMissingException
InvalidFlagArgumentException
UnknownFlagException
FileException
FileNotFoundException
NotFileException
How about adding a string[string] or a variant[string] to the
Exception class, so one can know details about the subclassed
exception without downcasting? How ugly would that be?
For instance:
...
catch (Exception ex) {
if ("transient" in ex.details) {
repeatOneMoreTi
Le 19/02/2012 09:02, Andrei Alexandrescu a écrit :
On 2/19/12 12:54 AM, H. S. Teoh wrote:
On Sun, Feb 19, 2012 at 12:43:58AM -0600, Andrei Alexandrescu wrote:
On 2/18/12 8:00 PM, H. S. Teoh wrote:
From this and other posts I'd say we need to design the base exception
classes better, for exampl
On Sunday, February 19, 2012 12:43:12 Jacob Carlborg wrote:
> On 2012-02-18 23:26, Jonathan M Davis wrote:
> > In the case of getopt, what we want is a GetOptException which is for
> > anything which goes wrong with getopt so that someone can catch that
> > exception type if they want to just handl
On Sunday, February 19, 2012 13:20:19 deadalnix wrote:
> Why is the executable size such a big issue ?
Some people complain bitterly about any additional size to the executable at
all, whether they use all of the symbols in it or not, and if they don't use
all of the symbols, then they're that m
On 2/19/12, Timon Gehr wrote:
> Concatenation only works if at least one of the types is an array.
Ah, good point. Still can be worked around:
struct Hash(Key, Val)
{
struct WrapVal(Val)
{
Val val;
auto opCat(Val rhs)
{
return [val] ~ rhs;
}
On 19/02/2012 02:19, Timon Gehr wrote:
On 02/19/2012 02:23 AM, Jonathan M Davis wrote:
One potential issue though is that not all base classes necessarily
share the
same constructors. Which ones would be grabbed? The ones from the
immediate
base class? All of them? Only the ones common to all?
Le 19/02/2012 02:43, Ben Davis a écrit :
On 19/02/2012 00:48, Jonathan M Davis wrote:
On Saturday, February 18, 2012 16:46:43 H. S. Teoh wrote:
I can't believe something this simple has to be explained so
elaborately. I thought all of us here knew how to use OO??
I think that the problem stem
Le 19/02/2012 13:32, Jonathan M Davis a écrit :
On Sunday, February 19, 2012 13:20:19 deadalnix wrote:
Why is the executable size such a big issue ?
Some people complain bitterly about any additional size to the executable at
all, whether they use all of the symbols in it or not, and if they d
On 19/02/2012 01:54, Jonathan M Davis wrote:
On Sunday, February 19, 2012 01:43:27 Ben Davis wrote:
- distinguish between 'bug' exceptions (e.g. null) and 'you're more
likely to want to catch this' exceptions (e.g. IO). Maybe the bug ones
should have been Errors, since people *usually* don't cat
On 2012-02-19 01:09, Andrei Alexandrescu wrote:
On 2/18/12 6:03 PM, Jonathan M Davis wrote:
On Saturday, February 18, 2012 17:30:10 Andrei Alexandrescu wrote:
The alternative is with virtuals. Do you see a lot of virtuals in base
exceptions? Do you see dramatically different interface for diffe
On 2012-02-19 01:09, Andrei Alexandrescu wrote:
On 2/18/12 6:03 PM, Jonathan M Davis wrote:
On Saturday, February 18, 2012 17:30:10 Andrei Alexandrescu wrote:
The alternative is with virtuals. Do you see a lot of virtuals in base
exceptions? Do you see dramatically different interface for diffe
Timon Gehr
> Indeed. I have never needed arr == null. Comparing class references to
> null using '==' is illegal. Probably the same could be done for arrays.
> Would also increase consistency.
Is this in Bugzilla already?
Bye,
bearophile
On 02/19/2012 01:54 PM, bearophile wrote:
Timon Gehr
Indeed. I have never needed arr == null. Comparing class references to
null using '==' is illegal. Probably the same could be done for arrays.
Would also increase consistency.
Is this in Bugzilla already?
Bye,
bearophile
I don't think so
The last dmd version I could use to actually build my project was dmd
2.056. Now I want to help finding those bugs that keep me from compiling
and I'm wondering how I can build repro cases for the ICEs I encounter.
I tried compiling with -v but that does not really give much information
about w
On 02/19/2012 09:26 AM, H. S. Teoh wrote:
On Sat, Feb 18, 2012 at 11:52:00PM -0800, Jonathan M Davis wrote:
[...]
So, while at first glance, it seems like a good idea, I think that it
has too many issues as-is to work. It might be possible to adjust the
idea to make it workable though. Right now
On 02/18/2012 07:52 PM, Andrei Alexandrescu 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 handling
in Phobos. From experience I humbly su
There are only a few options:
- Reduce your code using dustmite. I've never tried this, but I hear it
works.
- Use a debug version of dmd, or post the code and hope someone else debugs
it.
- Reduce the code manually.
The error you're getting occurs when merging two integral types together,
an
On 02/19/2012 02:24 PM, Benjamin Thaut wrote:
The last dmd version I could use to actually build my project was dmd
2.056. Now I want to help finding those bugs that keep me from compiling
and I'm wondering how I can build repro cases for the ICEs I encounter.
I tried compiling with -v but that d
Am 19.02.2012 02:47, schrieb Nick Sabalausky:
With exceptions in particular, I've often felt that we need some sort of
templated catch:
try {...}
catch(TypeTuple!(ExceptionA, ExceptionB) e)
{
// Common implementation, but NO need
// for that re-throwing abomination you'd
// inevit
I uploaded my little 2003 article on exception categorization to
github,
where I detailed my whole point_of_view_of_the_catch and
whole_program_invariant phylosophy for organizing clasess, and
compared
C++, .NET and Java hierarchies. Its not a professional article,
and I never wrote a translati
Hi all,
After writing this: http://saphyx.blogspot.com/2012/02/discovering-design.html
I had this: https://bitbucket.org/rolvseehuus/dxunit
It is a tiny framework for unit-testing in the style of NUnit and JUnit for D.
I hope somebody find it useful.
Improvements,suggestions and bugfixes are w
On 19/02/2012 03:31, Daniel Murphy wrote:
"Ben Davis" wrote in message
news:jhotcm$13ag$1...@digitalmars.com...
I've seen some line-blurring between 'null' and 'empty' for dynamic arrays
(non-associative). Specifically, I read that array.init returns null for
both static and dynamic, but I thin
On 2/19/12 5:22 AM, deadalnix wrote:
Le 19/02/2012 08:05, Andrei Alexandrescu a écrit :
How about a system in which you can say whether an exception is I/O
related, network related, recoverable or not, should be displayed to the
user or not, etc. Such is difficult to represent with inheritance a
At the moment, if a function has an inout parameter, it must have an inout
return type.
But this prevents doing stuff like
void test(ref inout(int)[] x, inout(int)[] y) {
x = y;
}
or passing the constancy through to a delegate instead of a return value.
A typical use case of t
On 2/19/12 6:27 AM, Juan Manuel Cabo wrote:
How about adding a string[string] or a variant[string] to the Exception
class, so one can know details about the subclassed exception without
downcasting?
That is a must for custom formatting and i18n.
Andrei
On 2/19/12 6:35 AM, deadalnix wrote:
Le 19/02/2012 09:02, Andrei Alexandrescu a écrit :
I'm thinking an error is transient if retrying the operation with the
same exact data may succeed. That's a definition that's simple,
useful, and easy to operate with.
[...]
But if that's the case, what's t
On 2/19/12 6:49 AM, Jacob Carlborg wrote:
On 2012-02-19 01:09, Andrei Alexandrescu wrote:
On 2/18/12 6:03 PM, Jonathan M Davis wrote:
On Saturday, February 18, 2012 17:30:10 Andrei Alexandrescu wrote:
The alternative is with virtuals. Do you see a lot of virtuals in base
exceptions? Do you see
On 2/19/12 6:35 AM, deadalnix wrote:
Le 19/02/2012 09:02, Andrei Alexandrescu a écrit :
I'm thinking an error is transient if retrying the operation with the
same exact data may succeed. That's a definition that's simple,
useful, and easy to operate with.
[...]
But if that's the case, what's t
On 2/19/12 6:48 AM, Jacob Carlborg wrote:
On 2012-02-19 01:09, Andrei Alexandrescu wrote:
On 2/18/12 6:03 PM, Jonathan M Davis wrote:
On Saturday, February 18, 2012 17:30:10 Andrei Alexandrescu wrote:
The alternative is with virtuals. Do you see a lot of virtuals in base
exceptions? Do you see
On 19.02.2012 14:24, Benjamin Thaut wrote:
The last dmd version I could use to actually build my project was dmd
2.056. Now I want to help finding those bugs that keep me from compiling
and I'm wondering how I can build repro cases for the ICEs I encounter.
I tried compiling with -v but that does
On 19-02-2012 15:41, Andrei Alexandrescu wrote:
On 2/19/12 7:31 AM, Timon Gehr wrote:
On 02/19/2012 09:26 AM, H. S. Teoh wrote:
On Sat, Feb 18, 2012 at 11:52:00PM -0800, Jonathan M Davis wrote:
[...]
So, while at first glance, it seems like a good idea, I think that it
has too many issues as-i
On 2/19/12 7:31 AM, Timon Gehr wrote:
On 02/19/2012 09:26 AM, H. S. Teoh wrote:
On Sat, Feb 18, 2012 at 11:52:00PM -0800, Jonathan M Davis wrote:
[...]
So, while at first glance, it seems like a good idea, I think that it
has too many issues as-is to work. It might be possible to adjust the
ide
On 2/19/12 8:44 AM, Alex Rønne Petersen wrote:
On 19-02-2012 15:41, Andrei Alexandrescu wrote:
That helps. This quite nicely illustrates that types don't necessarily
need to proliferate. Something not much more constraining can be done
today:
try {
...
} catch(IOException e)
{
if (e.errno !in s
On 2012-02-19 13:27, Juan Manuel Cabo wrote:
How about adding a string[string] or a variant[string] to the Exception
class, so one can know details about the subclassed exception without
downcasting? How ugly would that be?
For instance:
...
catch (Exception ex) {
if ("transient" in ex.details)
On 19-02-2012 15:46, Andrei Alexandrescu wrote:
On 2/19/12 8:44 AM, Alex Rønne Petersen wrote:
On 19-02-2012 15:41, Andrei Alexandrescu wrote:
That helps. This quite nicely illustrates that types don't necessarily
need to proliferate. Something not much more constraining can be done
today:
try
I think the difference between chording and non-chording styles of
input depends on the person. I have dyspraxia, which affects my fine
motor control, so remembering and performing complex key sequences
(such as emacs' keyboard shortcuts) is difficult for me, hell I have
difficulty correctly typing
Okay, so it came up a couple of times, but the questions is, what are we
going to do about it?
size_t and ptrdiff_t are incomplete, and represent non-complimentary
signed/unsigned halves of the requirement.
There are TWO types needed, register size, and pointer size. Currently,
these are assumed t
On Sun, Feb 19, 2012 at 12:44 PM, Alex Rønne Petersen
wrote:
> On 19-02-2012 15:41, Andrei Alexandrescu wrote:
>>
>> On 2/19/12 7:31 AM, Timon Gehr wrote:
>>>
>>> On 02/19/2012 09:26 AM, H. S. Teoh wrote:
On Sat, Feb 18, 2012 at 11:52:00PM -0800, Jonathan M Davis wrote:
[...]
>
On Sun, Feb 19, 2012 at 12:51 PM, Alex Rønne Petersen
wrote:
> On 19-02-2012 15:46, Andrei Alexandrescu wrote:
>>
>> On 2/19/12 8:44 AM, Alex Rønne Petersen wrote:
>>>
>>> On 19-02-2012 15:41, Andrei Alexandrescu wrote:
That helps. This quite nicely illustrates that types don't necessari
"Ben Davis" wrote in message
news:jhr0qf$24sj$1...@digitalmars.com...
> On 19/02/2012 03:31, Daniel Murphy wrote:
>> Except for this magic initialization, AAs behave the same as classes - ie
>> a
>> reference type.
>
> That's not quite true, because 'length' is passed around by value
> alongsid
On 2012-02-19 10:26, Jonathan M Davis wrote:
On Sunday, February 19, 2012 19:00:20 Daniel Murphy wrote:
I wasn't really serious about implicit fallthrough.
Lately, it seems like I can never tell whether anyone's being serious or not
online. :)
Out of the syntaxes I could come up with:
catch(
On 19/02/2012 14:59, Manu wrote:
Okay, so it came up a couple of times, but the questions is, what are we going
to do about it?
size_t and ptrdiff_t are incomplete, and represent non-complimentary
signed/unsigned
halves of the requirement.
There are TWO types needed, register size, and pointer
Are you sure about that?
My understanding is java works the same way in terms of re-evaluating stack
traces, except that it has
'throw;' which keeps the original intact, specifically for rethrowing.
"Jose Armando Garcia" wrote in message
news:mailman.601.1329663665.20196.digitalmar...@puremagi
Hey Guys,
I have used clang-complete in Vim for C/C++ development and it is
brilliant. As far as I am aware, this mostly due to the fact that it
uses clang to find valid suggestions for the line. I don't know much
about how autocomplete works in general, or clang-complete
specifically, but it woul
On 19-02-2012 16:00, Jose Armando Garcia wrote:
On Sun, Feb 19, 2012 at 12:44 PM, Alex Rønne Petersen
wrote:
On 19-02-2012 15:41, Andrei Alexandrescu wrote:
On 2/19/12 7:31 AM, Timon Gehr wrote:
On 02/19/2012 09:26 AM, H. S. Teoh wrote:
On Sat, Feb 18, 2012 at 11:52:00PM -0800, Jonathan
On 17/02/2012 06:09, bcs wrote:
Any language that is designed to be easy for amateurs to use will be used by
amateurs, and
only by amateurs.
Do you consider either VB or Python to fall under that category?
Stewart.
On Sun, Feb 19, 2012 at 1:08 PM, Daniel Murphy wrote:
> Are you sure about that?
>
> My understanding is java works the same way in terms of re-evaluating stack
> traces, except that it has
> 'throw;' which keeps the original intact, specifically for rethrowing.
>
Quoting the source of all Java t
Le 19/02/2012 15:41, Andrei Alexandrescu a écrit :
On 2/19/12 7:31 AM, Timon Gehr wrote:
On 02/19/2012 09:26 AM, H. S. Teoh wrote:
On Sat, Feb 18, 2012 at 11:52:00PM -0800, Jonathan M Davis wrote:
[...]
So, while at first glance, it seems like a good idea, I think that it
has too many issues a
On 19 February 2012 17:09, Stewart Gordon wrote:
> On 19/02/2012 14:59, Manu wrote:
>
>> Okay, so it came up a couple of times, but the questions is, what are we
>> going to do about it?
>>
>> size_t and ptrdiff_t are incomplete, and represent non-complimentary
>> signed/unsigned
>> halves of the
On 19/02/2012 15:05, Daniel Murphy wrote:
"Ben Davis" wrote in message
news:jhr0qf$24sj$1...@digitalmars.com...
On 19/02/2012 03:31, Daniel Murphy wrote:
Except for this magic initialization, AAs behave the same as classes - ie
a
reference type.
That's not quite true, because 'length' is pas
On Sun, Feb 19, 2012 at 1:11 PM, Alex Rønne Petersen
wrote:
> On 19-02-2012 16:00, Jose Armando Garcia wrote:
>>
>> On Sun, Feb 19, 2012 at 12:44 PM, Alex Rønne Petersen
>> wrote:
>>>
>>> On 19-02-2012 15:41, Andrei Alexandrescu wrote:
On 2/19/12 7:31 AM, Timon Gehr wrote:
>
>
On 19-02-2012 16:26, Manu wrote:
On 19 February 2012 17:09, Stewart Gordon mailto:smjg_1...@yahoo.com>> wrote:
On 19/02/2012 14:59, Manu wrote:
Okay, so it came up a couple of times, but the questions is,
what are we going to do about it?
size_t and ptrdiff_t are in
Am 19.02.2012 14:44, schrieb Timon Gehr:
On 02/19/2012 02:24 PM, Benjamin Thaut wrote:
The last dmd version I could use to actually build my project was dmd
2.056. Now I want to help finding those bugs that keep me from compiling
and I'm wondering how I can build repro cases for the ICEs I encou
On 02/19/2012 03:27 PM, Stewart Gordon wrote:
At the moment, if a function has an inout parameter, it must have an
inout return type.
But this prevents doing stuff like
void test(ref inout(int)[] x, inout(int)[] y) {
x = y;
}
or passing the constancy through to a delegate instead of a return v
The call is rewriten to _aa_len(aa) and checks for null.
This can almost be done with a normal class, except the compiler inserts a
null check into each member function, iirc.
I guess that's another bit of magic that can't be handled simply.
It can still be done with a struct:
struct AAPimpl
{
On Sun, Feb 19, 2012 at 1:11 PM, Alex Rønne Petersen
wrote:
> On 19-02-2012 16:00, Jose Armando Garcia wrote:
>>
>> On Sun, Feb 19, 2012 at 12:44 PM, Alex Rønne Petersen
>> wrote:
>>>
>>> On 19-02-2012 15:41, Andrei Alexandrescu wrote:
On 2/19/12 7:31 AM, Timon Gehr wrote:
>
>
Ah, I was probably thinking of C#
Am 19.02.2012 15:41, schrieb Don:
On 19.02.2012 14:24, Benjamin Thaut wrote:
The last dmd version I could use to actually build my project was dmd
2.056. Now I want to help finding those bugs that keep me from compiling
and I'm wondering how I can build repro cases for the ICEs I encounter.
I tr
"Benjamin Thaut" wrote in message
news:jhr584$2d1v$1...@digitalmars.com...
> Thank you very much that helped a lot. I was able to reduce it to the
> following code:
>
> class Foo
> {
>
> @property EntityId entityId()
> {
> return EntityId(3);
> }
>
> }
>
> struct EntityId
> {
> uint
Well, since keys would be string, you can define them at the base
class.
So, FileException can define a few detail names that you know are
used in its derived classes. And so, Exception can define detail
names that are standard for all classes.
So it would look like:
class FileException {
On 2/19/12 8:54 AM, Jacob Carlborg wrote:
On 2012-02-19 13:27, Juan Manuel Cabo wrote:
How about adding a string[string] or a variant[string] to the Exception
class, so one can know details about the subclassed exception without
downcasting? How ugly would that be?
For instance:
...
catch (Exc
Am 19.02.2012 16:44, schrieb Daniel Murphy:
"Benjamin Thaut" wrote in message
news:jhr584$2d1v$1...@digitalmars.com...
Thank you very much that helped a lot. I was able to reduce it to the
following code:
class Foo
{
@property EntityId entityId()
{
return EntityId(3);
}
}
stru
On 2/19/12 7:37 AM, Timon Gehr wrote:
On 02/18/2012 07:52 PM, Andrei Alexandrescu 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 handlin
Benjamin Thaut:
> Thank you very much that helped a lot. I was able to reduce it to the
> following code:
>
> class Foo
> {
>
>@property EntityId entityId()
>{
> return EntityId(3);
>}
>
> }
>
> struct EntityId
> {
>uint id;
>
>alias id this;
>
>this(uint id)
>
On Sunday, 19 February 2012 at 00:50:07 UTC, Jonathan M Davis
wrote:
On Saturday, February 18, 2012 16:46:43 H. S. Teoh wrote:
I can't believe something this simple has to be explained so
elaborately. I thought all of us here knew how to use OO??
I think that the problem stems from people freq
On 2/19/12 4:30 AM, Juan Manuel Cabo wrote:
Hello D community! This is my first post!! I hope I can bring clarity to
all this. If not, I apologize.
[snip]
Thanks for an insightful post. If you found the time, it would be great
if you could translate your paper on exceptions from Spanish.
And
"Andrei Alexandrescu" wrote in message
news:jhr0vq$24t0$1...@digitalmars.com...
> On 2/19/12 5:22 AM, deadalnix wrote:
>> Le 19/02/2012 08:05, Andrei Alexandrescu a écrit :
>>> How about a system in which you can say whether an exception is I/O
>>> related, network related, recoverable or not, sh
On 2/19/12 3:26 AM, Jonathan M Davis wrote:
On Sunday, February 19, 2012 19:00:20 Daniel Murphy wrote:
I wasn't really serious about implicit fallthrough.
Lately, it seems like I can never tell whether anyone's being serious or not
online. :)
Out of the syntaxes I could come up with:
catch(E
On Sunday, 19 February 2012 at 15:26:27 UTC, Manu wrote:
There is code that assumes size_t is the width of the pointer
When is this not true? I can only think of 16-bit far pointers.
On 2/19/12 3:17 AM, Jonathan M Davis wrote:
"As much information as possible" is way more than a transient property. If my
code is going to retry or do something else or give up, it needs enough
information to know what went wrong, not just whether the function which was
called think it might wor
"Andrei Alexandrescu" wrote in message
news:jhr67g$2dup$4...@digitalmars.com...
>
> The Java7 syntax looks meaningful to me, too - you want to catch the union
> type. A possibility that wouldn't change the language for us would be to
> catch Algebraic!(Ex1, Ex2).
>
> Andrei
That would still re
"Vladimir Panteleev" wrote in message
news:valucopzdhxdjymkg...@forum.dlang.org...
> On Sunday, 19 February 2012 at 15:26:27 UTC, Manu wrote:
>> There is code that assumes size_t is the width of the pointer
>
> When is this not true? I can only think of 16-bit far pointers.
8-bit embedded quite
On Sunday, 19 February 2012 at 15:31:32 UTC, Benjamin Thaut wrote:
Which dmd version should I use to build DustMite?
I tried 2.055 and 2.058 but DustMite crashes half way through
the reductino process without a message (I'm using windows)
I've never heard of a problem like this. Is the DustMit
On 2/19/12 3:15 AM, H. S. Teoh wrote:
I don't understand. So instead of providing enough information to the
caller about the nature of the problem, you're essentially handing them
an anonymous note saying "A generic problem occurred, which _may_ go
away if you retry. I have no further informatio
Am 19.02.2012 17:06, schrieb Vladimir Panteleev:
On Sunday, 19 February 2012 at 15:31:32 UTC, Benjamin Thaut wrote:
Which dmd version should I use to build DustMite?
I tried 2.055 and 2.058 but DustMite crashes half way through the
reductino process without a message (I'm using windows)
I've n
On 2/19/12 2:49 AM, H. S. Teoh wrote:
[snip]
To me, this is a giant hint that OOP is a good solution. You want a
class hierarchy rooted at Exception. And groups of related exceptions
probably should be rooted under their respective base classes under
Exception.
If you have a better way to solve
On 19 February 2012 18:03, Vladimir Panteleev
wrote:
> On Sunday, 19 February 2012 at 15:26:27 UTC, Manu wrote:
>
>> There is code that assumes size_t is the width of the pointer
>>
>
> When is this not true? I can only think of 16-bit far pointers.
>
Ignoring small embedded systems (for which it
On 2/19/12 9:50 AM, so wrote:
On Sunday, 19 February 2012 at 00:50:07 UTC, Jonathan M Davis wrote:
On Saturday, February 18, 2012 16:46:43 H. S. Teoh wrote:
I can't believe something this simple has to be explained so
elaborately. I thought all of us here knew how to use OO??
I think that the
On 2/19/12 9:56 AM, Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:jhr0vq$24t0$1...@digitalmars.com...
On 2/19/12 5:22 AM, deadalnix wrote:
Le 19/02/2012 08:05, Andrei Alexandrescu a écrit :
How about a system in which you can say whether an exception is I/O
related, netwo
1 - 100 of 234 matches
Mail list logo
