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 an awful syntax.
>
> Maybe we should introduce implicit 'catch fallthrough':
>
> void fun()
> {
> try { so
"Jonathan M Davis" wrote in message
news:mailman.582.1329634661.20196.digitalmar...@puremagic.com...
> On Sunday, February 19, 2012 16:59:49 Daniel Murphy wrote:
>> "Nick Sabalausky" wrote in message
>> news:jhprac$2aj$1...@digitalmars.com...
>>
>> > The only problem I've ever had with them is
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
> >> isTransient that tells caller code wh
On 2/18/12 8:45 PM, Jonathan M Davis wrote:
On Saturday, February 18, 2012 20:28:32 Andrei Alexandrescu wrote:
On 2/18/12 6:36 PM, H. S. Teoh wrote:
Note also, that an elaborated exception hierarchy lets you attach
additional specific information that might be useful in error recovery.
For exam
On Sunday, February 19, 2012 00:21:38 Robert Jacques wrote:
> Not to jump on you in particular :) but bad user parameters should never be
> treated as exceptional. Even bad 'internal' parameters that are passed via
> the external API aren't exceptional. Programmers being lazy about input
> paramete
On Sunday, February 19, 2012 16:59:49 Daniel Murphy wrote:
> "Nick Sabalausky" wrote in message
> news:jhprac$2aj$1...@digitalmars.com...
>
> > The only problem I've ever had with them is that there's no templated
> > catch blocks, so you can't handle two different exceptions with the same
> > co
On 2/18/12 11:09 PM, Jim Hewes wrote:
I think of exception handling as tied to contract programming. A
function has a specific job that it's supposed to do. If for any reason
it cannot do that job successfully, an exception should be thrown. That
can include even bad parameters (although if you h
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 that tells caller code whether
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 that tells caller code whether retrying might help.
Just because an exception is transient doesn't mean it ma
On Sat, 18 Feb 2012 23:08:21 -0600, Sean Cavanaugh
wrote:
On 2/18/2012 11:07 PM, Walter Bright wrote:
On 2/18/2012 8:08 PM, bearophile wrote:
To improve this discussion a small benchmark is useful to see how much
bloat this actually causes.
It'll increase with reflection and perfect garbage
On Sat, 18 Feb 2012 20:03:51 -0600, Xinok wrote:
On Sunday, 19 February 2012 at 00:49:56 UTC, Robert Jacques wrote:
On Sat, 18 Feb 2012 18:33:01 -0600, Xinok
wrote:
While reading "The Right Approach to Exceptions", it gave me
this
idea. The user would declare a list of variables of differen
On Sat, 18 Feb 2012 23:09:17 -0600, Jim Hewes wrote:
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 jum
I agree, and I doubt it was intentional.
if (arr) should mean if (arr.length && arr.ptr)
But since you can only get (arr.length != 0 && arr.ptr == null) when doing
unsafe things with arrays, I think it's entirely reasonable to use
if (arr) -> if (arr.length)
This is what I expected.
Much like w
"Nick Sabalausky" wrote in message
news:jhprac$2aj$1...@digitalmars.com...
> The only problem I've ever had with them is that there's no templated
> catch blocks, so you can't handle two different exceptions with the same
> code without violating DRY or worse: catching the common base type and
On 02/19/2012 06:15 AM, Bernard Helyer wrote:
On Sunday, 19 February 2012 at 04:01:45 UTC, Timon Gehr wrote:
On 02/19/2012 04:56 AM, Bernard Helyer wrote:
On Sunday, 19 February 2012 at 03:33:14 UTC, Timon Gehr wrote:
That would potentially break code.
It would also potentially fix code.
W
On Sat, 18 Feb 2012 20:21:46 -0600, Jonathan M Davis
wrote:
On Saturday, February 18, 2012 19:59:52 Robert Jacques wrote:
But you _always_ know what went wrong:
No you don't. Take getopt for instance. If I want to appropriately handle what
went wrong that caused getopt to throw an exception
"Walter Bright" wrote in message
news:jhpqdj$30t6$1...@digitalmars.com...
> (Also, having a large number of exception types is going to produce a lot
> of program size bloat. Remember, for EVERY class type, you've got the
> vtbl[], the .init data, and the TypeInfo. Going to town on exception ty
On Sunday, 19 February 2012 at 04:01:45 UTC, Timon Gehr wrote:
On 02/19/2012 04:56 AM, Bernard Helyer wrote:
On Sunday, 19 February 2012 at 03:33:14 UTC, Timon Gehr wrote:
That would potentially break code.
It would also potentially fix code.
Well that's the stupidest thing I've read today.
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 particular for using the phrase "exceptions
On 2/18/2012 11:07 PM, Walter Bright wrote:
On 2/18/2012 8:08 PM, bearophile wrote:
To improve this discussion a small benchmark is useful to see how much
bloat this actually causes.
It'll increase with reflection and perfect garbage collection.
Are these coming? :)
On 2/18/2012 8:08 PM, bearophile wrote:
To improve this discussion a small benchmark is useful to see how much bloat
this actually causes.
It'll increase with reflection and perfect garbage collection.
On 2/18/12 10:14 PM, Nick Sabalausky wrote:
"H. S. Teoh" wrote in message
news:mailman.556.1329612309.20196.digitalmar...@puremagic.com...
I can't believe something this simple has to be explained so
elaborately. I thought all of us here knew how to use OO??
My thoughts exactly. Andrei is a
On 2/18/12 9:50 PM, Bernard Helyer wrote:
On Sunday, 19 February 2012 at 02:27:07 UTC, Andrei Alexandrescu wrote:
On 2/18/12 6:28 PM, Jonathan M Davis wrote:
On Saturday, February 18, 2012 17:53:52 Andrei Alexandrescu wrote:
On 2/18/12 5:47 PM, Jakob Ovrum wrote:
you are basically arguing aga
"Bernard Helyer" wrote in message
news:npnjfynxdnpykaeml...@forum.dlang.org...
> On Sunday, 19 February 2012 at 02:27:07 UTC, Andrei Alexandrescu wrote:
>> On 2/18/12 6:28 PM, Jonathan M Davis wrote:
>>> On Saturday, February 18, 2012 17:53:52 Andrei Alexandrescu wrote:
On 2/18/12 5:47 PM, J
Andrei Alexandrescu wrote:
>
>catching by type is most of the time useless.
Andrei Alexandrescu wrote...
> I should note that the above does little in the way of putting an argument
> to the table. It appeals to subjective qualifications ("poorly designed",
> "well designed")
/facepalm
Just on
"H. S. Teoh" wrote in message
news:mailman.556.1329612309.20196.digitalmar...@puremagic.com...
>
> I can't believe something this simple has to be explained so
> elaborately. I thought all of us here knew how to use OO??
>
My thoughts exactly. Andrei is a very intelligent, very capable programme
Sean Cavanaug:
> In the Von Neumann model this has been made difficult by the stack
> itself. Thinking of exceptions as they are currently implemented in
> Java, C++, D, etc is automatically artificially constraining how they
> need to work.
It's interesting to take a look at how "exceptions"
Walter:
> (Also, having a large number of exception types is going to produce a lot of
> program size bloat. Remember, for EVERY class type, you've got the vtbl[],
> the
> .init data, and the TypeInfo. Going to town on exception types can really add
> this up.)
To improve this discussion a sm
On 02/19/2012 05:01 AM, Timon Gehr wrote:
On 02/19/2012 04:56 AM, Bernard Helyer wrote:
On Sunday, 19 February 2012 at 03:33:14 UTC, Timon Gehr wrote:
That would potentially break code.
It would also potentially fix code.
Well that's the stupidest thing I've read today. Can you point to peo
On 02/19/2012 04:56 AM, Bernard Helyer wrote:
On Sunday, 19 February 2012 at 03:33:14 UTC, Timon Gehr wrote:
That would potentially break code.
It would also potentially fix code.
Well that's the stupidest thing I've read today. Can you point to people
using it in the way that you expect? Be
On Sunday, February 19, 2012 04:56:13 Bernard Helyer wrote:
> On Sunday, 19 February 2012 at 03:33:14 UTC, Timon Gehr wrote:
> >> That would potentially break code.
> >
> > It would also potentially fix code.
>
> Well that's the stupidest thing I've read today. Can you point to
> people using it
On Sunday, 19 February 2012 at 03:33:14 UTC, Timon Gehr wrote:
That would potentially break code.
It would also potentially fix code.
Well that's the stupidest thing I've read today. Can you point to
people using it in the way that you expect? Besides which, that's
just about the worst way
On Sunday, February 19, 2012 04:52:48 Timon Gehr wrote:
> That is true. It is also what worries me. Having cast(bool) evaluate to
> false for empty arrays is intuitive and has massive precedent in other
> programming languages.
If we think that the problems solved by it are greater than those caus
On 02/19/2012 04:38 AM, Jonathan M Davis wrote:
On Sunday, February 19, 2012 04:24:46 Timon Gehr wrote:
But the fact that == treats null and [] as the same thing _does_
understandably cloud things a bit.
Nothing cloudy about that, that is sane behaviour and I want it to be
consistently carried
On Sunday, 19 February 2012 at 02:27:07 UTC, Andrei Alexandrescu
wrote:
On 2/18/12 6:28 PM, Jonathan M Davis wrote:
On Saturday, February 18, 2012 17:53:52 Andrei Alexandrescu
wrote:
On 2/18/12 5:47 PM, Jakob Ovrum wrote:
you are basically arguing against exceptions here
I must have argued m
"Sean Cavanaugh" wrote in message
news:jhpr9t$29i$1...@digitalmars.com...
>
> My C++ experience revolves around some rather large codebases that do not
> have exceptions enabled at all. The more I look into seeing what it would
> take to start using them, all I see are some pretty huge downsid
On 2/18/2012 7:56 PM, Zach wrote:
On Sunday, 19 February 2012 at 01:29:40 UTC, Nick Sabalausky wrote:
Another one for the file of "Crazy shit Andrei says" ;)
From experience, I (and clearly many others here) find a sparse, flat
exception hierarchy to be problematic and limiting. But even with a
"Zach" wrote in message
news:tpxbylbgpvarpzzlp...@forum.dlang.org...
> On Sunday, 19 February 2012 at 01:29:40 UTC, Nick Sabalausky wrote:
>> Another one for the file of "Crazy shit Andrei says" ;)
>>
>> From experience, I (and clearly many others here) find a sparse, flat
>> exception hierarchy
On Sunday, February 19, 2012 04:33:14 Timon Gehr wrote:
> Why? (step back a moment and stop thinking about what you know about
> DMDs implementation semantics and then answer)
Because of the whole nonsense of null and empty being treated the same in some
circumstances and not in others. I'm immed
On Sunday, February 19, 2012 04:24:46 Timon Gehr wrote:
> > But the fact that == treats null and [] as the same thing _does_
> > understandably cloud things a bit.
>
> Nothing cloudy about that, that is sane behaviour and I want it to be
> consistently carried out everywhere. ('is' can still do a
On 02/19/2012 04:17 AM, Jonathan M Davis wrote:
On Sunday, February 19, 2012 04:13:02 Timon Gehr wrote:
On 02/19/2012 03:24 AM, bearophile wrote:
Timon Gehr:
Is there any reason for empty arrays to evaluate to true? This is very
bug prone.
Related?
http://d.puremagic.com/issues/show_bug.cgi?
"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 (for
>> instance, if I'm actually setting up ssh) *then* I'll e
"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 think I also read that a dynamic array's
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
NotDirException
AccessDeniedException
I died
On Saturday, 18 February 2012 at 08:18:32 UTC, Denis Shelomovskij
wrote:
Some remarks:
0. `string[] args` isn't needed;
1. `delegate` is not needed;
2. `isSomeString!(T)` can be replaced by `isSomeString!T`;
3. `static if` can be replaced by `auto m =
mixin(isSomeString!T ? "n ~ i" : "n + i");`;
On 02/19/2012 03:23 AM, Jonathan M Davis wrote:
On Sunday, February 19, 2012 03:01:55 Timon Gehr wrote:
Why does the following code behave funny?
void main(){
string x = " "[1..1];
writeln(cast(bool)x); // true
char[] y = [' '][1..1];
writeln(cast(bool)y); // false
}
Is
On Sunday, February 19, 2012 04:13:02 Timon Gehr wrote:
> On 02/19/2012 03:24 AM, bearophile wrote:
> > Timon Gehr:
> >> Is there any reason for empty arrays to evaluate to true? This is very
> >> bug prone.
> >
> > Related?
> > http://d.puremagic.com/issues/show_bug.cgi?id=4733
> >
> > Bye,
> >
On 02/19/2012 03:24 AM, bearophile wrote:
Timon Gehr:
Is there any reason for empty arrays to evaluate to true? This is very
bug prone.
Related?
http://d.puremagic.com/issues/show_bug.cgi?id=4733
Bye,
bearophile
Roughly. I want it to be allowed, but to test the length instead of ptr.
On 2/18/12 8:38 PM, Jonathan M Davis wrote:
On Saturday, February 18, 2012 20:30:45 Andrei Alexandrescu wrote:
On 2/18/12 6:40 PM, H. S. Teoh wrote:
One word: internationalization. Then toString() falls flat on its face.
No. I happen to have some expertise in the area as I've participated to
On Saturday, February 18, 2012 20:28:32 Andrei Alexandrescu wrote:
> On 2/18/12 6:36 PM, H. S. Teoh wrote:
> > Note also, that an elaborated exception hierarchy lets you attach
> > additional specific information that might be useful in error recovery.
> > For example, FileException may have a fiel
On 2/18/12 7:17 PM, H. S. Teoh wrote:
On Sat, Feb 18, 2012 at 04:28:25PM -0800, Jonathan M Davis wrote:
[...]
C++ is a horrible example of how exceptions should be done, so if
you're basing what you want off of that, then that makes me think that
you should be better familiar with how other, mor
On Saturday, February 18, 2012 20:30:45 Andrei Alexandrescu wrote:
> On 2/18/12 6:40 PM, H. S. Teoh wrote:
> > One word: internationalization. Then toString() falls flat on its face.
>
> No. I happen to have some expertise in the area as I've participated to
> two large and heavily internationaliz
On 2/18/12 6:40 PM, H. S. Teoh wrote:
One word: internationalization. Then toString() falls flat on its face.
No. I happen to have some expertise in the area as I've participated to
two large and heavily internationalized systems. i18n has everything to
do with string tables and formatting te
On 2/18/12 6:36 PM, H. S. Teoh wrote:
Note also, that an elaborated exception hierarchy lets you attach
additional specific information that might be useful in error recovery.
For example, FileException may have a field containing the filename that
caused the error, so that if the program is proc
On 2/18/12 6:28 PM, Jonathan M Davis wrote:
On Saturday, February 18, 2012 17:53:52 Andrei Alexandrescu wrote:
On 2/18/12 5:47 PM, Jakob Ovrum wrote:
you are basically arguing against exceptions here
I must have argued my question and point very poorly.
You definitely seem to be arguing for
Timon Gehr:
> Is there any reason for empty arrays to evaluate to true? This is very
> bug prone.
Related?
http://d.puremagic.com/issues/show_bug.cgi?id=4733
Bye,
bearophile
On Sunday, February 19, 2012 03:01:55 Timon Gehr wrote:
> Why does the following code behave funny?
>
> void main(){
> string x = " "[1..1];
> writeln(cast(bool)x); // true
> char[] y = [' '][1..1];
> writeln(cast(bool)y); // false
> }
>
> Is there any reason for empty arrays
On Saturday, February 18, 2012 19:59:52 Robert Jacques wrote:
> But you _always_ know what went wrong:
No you don't. Take getopt for instance. If I want to appropriately handle what
went wrong that caused getopt to throw an exception, I need information on
what went wrong. I need to know what fl
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?
There is only one base class. Inheriti
"bcs" wrote in message
news:jhonpv$neg$1...@digitalmars.com...
> On 02/18/2012 09:10 AM, Nick Sabalausky wrote:
>>
>> I've heard a lot of people say that about vi(m), but in my (admittedly
>> somewhat limited) experience, I've never come across a (Li|U)n[ui]x
>> system
>> that didn't have nano o
On 02/19/2012 12:40 AM, Andrej Mitrovic wrote:
On 2/19/12, Andrej Mitrovic wrote:
Chunk[] tempVar = chunks.get("", null) ~ new Chunk();
I've tried making a wrapper type that does this behind the scenes but
it won't work:
struct Hash(Key, Val)
{
Val[Key] aa;
Val opIndex(Key key
On 2/19/12, Ben Davis wrote:
> That would then make it an entirely separate issue and completely not
> Exception-specific.
Yes I meant in the general case not just Exception. Exception is just
a regular class.
On 19.02.2012 02:17, H. S. Teoh wrote:
The basic problem with C++ exceptions is that it allows you to throw
literally *anything*. Which is nice and generous, but not having a
common root to all exceptions cripples the system, because there is no
functionality that can be depended upon, like toSt
Why does the following code behave funny?
void main(){
string x = " "[1..1];
writeln(cast(bool)x); // true
char[] y = [' '][1..1];
writeln(cast(bool)y); // false
}
Is there any reason for empty arrays to evaluate to true? This is very
bug prone.
On Sunday, 19 February 2012 at 00:49:56 UTC, Robert Jacques wrote:
On Sat, 18 Feb 2012 18:33:01 -0600, Xinok
wrote:
While reading "The Right Approach to Exceptions", it gave me
this
idea. The user would declare a list of variables of different
types as case statements, and the variable with
On Sat, 18 Feb 2012 19:13:02 -0600, Jonathan M Davis
wrote:
On Saturday, February 18, 2012 19:01:31 Robert Jacques wrote:
That an argument of an internationalization module as part of the standard
library, not for or against a particular exception module. I don't know
what a good/robust modul
On Sunday, 19 February 2012 at 01:29:40 UTC, Nick Sabalausky
wrote:
Another one for the file of "Crazy shit Andrei says" ;)
From experience, I (and clearly many others here) find a
sparse, flat exception hierarchy to be problematic and
limiting. But even with a rich detailed exception hierarch
On Sat, Feb 18, 2012 at 05:47:58PM -0600, Andrei Alexandrescu wrote:
> On 2/18/12 1:41 PM, H. S. Teoh wrote:
[...]
> >It's only useless because of a poorly-designed exception hierarchy.
> >Java, for example, has useful things like FileNotFoundException,
> >DiskFullException, etc., that you can catc
On Sunday, February 19, 2012 01:43:27 Ben Davis wrote:
> I can assure you they get misused in Java too. Most people write this:
Oh yes. It's not like the fact that their exception hierarchy is good means
that people don't misuse it. Far too many people try and ignore errors in any
language. And
"Xinok" wrote in message
news:yeuigezlevjbhgufw...@forum.dlang.org...
> While reading "The Right Approach to Exceptions", it gave me this idea.
> The user would declare a list of variables of different types as case
> statements, and the variable with matches the type of the switch
> expressio
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 stems from people frequently using exceptions
On Saturday, February 18, 2012 23:26:35 Jose Armando Garcia wrote:
> I think that is a good compromise. The one thing we need to solve is
> that for example Oracle's error code may collide with POSIX error
> code. This is why I suggested using namespace but there may be other
> solutions.
What rel
"Andrei Alexandrescu" wrote in message
news:jhos0l$102t$1...@digitalmars.com...
> There's a discussion that started in a pull request:
>
> https://github.com/alexrp/phobos/commit/4b87dcf39efeb4ddafe8fe99a0ef9a529c0dcaca
>
What the hell...? It says "5 notes on commit", but only 2 are shown (both
On Sat, Feb 18, 2012 at 11:19 PM, Jonathan M Davis wrote:
> On Saturday, February 18, 2012 22:54:37 Jose Armando Garcia wrote:
>> You basically agree that we need error codes inside the exception to
>> handle database errors correctly. What about POSIX error codes?
>> Basically in some cases you a
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 super
> > constructors and calling th
On Saturday, February 18, 2012 22:54:37 Jose Armando Garcia wrote:
> You basically agree that we need error codes inside the exception to
> handle database errors correctly. What about POSIX error codes?
> Basically in some cases you are solving the problem using inheritance
> in other cases you ar
Andrei Alexandrescu wrote:
> why are various error deserving of their own types.
1)
If an error can be forseen and one and only one solution is known and
computable, then the only throwable exception is "not yet implemented"
2)
In all other cases the human operator must be informed about the c
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 super
> constructors and calling through to them" and can be used in ANY class
> hierarchy (not necessaril
On Sat, Feb 18, 2012 at 04:28:25PM -0800, Jonathan M Davis wrote:
[...]
> C++ is a horrible example of how exceptions should be done, so if
> you're basing what you want off of that, then that makes me think that
> you should be better familiar with how other, more recent languages
> use them (thou
On 18/02/2012 21:07, Andrej Mitrovic wrote:
On 2/18/12, Nathan M. Swan wrote:
It would be nice if there was a mixin template that creates an
exception class that acts like this; making similar exception
classes is annoying.
It would be even nicer if we didn't need a mixin for classes that
sim
On Saturday, February 18, 2012 19:01:31 Robert Jacques wrote:
> That an argument of an internationalization module as part of the standard
> library, not for or against a particular exception module. I don't know
> what a good/robust module would look like, but many open source projects
> simply us
H. S. Teoh:
> Error
> +--Exception
> +--GetOptException (bad name, I prefer CommandLineException)
> | +--FlagArgumentMissingException
> | +--InvalidFlagArgumentException
> | +--UnknownFlagException
> +--FileException
> | +--FileNotFoundException
> | +-
On Sat, 18 Feb 2012 18:40:50 -0600, H. S. Teoh wrote:
On Sat, Feb 18, 2012 at 06:09:30PM -0600, Andrei Alexandrescu wrote:
On 2/18/12 6:03 PM, Jonathan M Davis wrote:
[...]
>If we have GetOptException, it should have a variable for which flag failed.
>Exception doesn't have that. And what if
Le 19/02/2012 01:36, H. S. Teoh a écrit :
On Sat, Feb 18, 2012 at 05:13:16PM -0600, Andrei Alexandrescu wrote:
On 2/18/12 4:26 PM, Jonathan M Davis wrote (abridged):
GetOptException
FlagArgumentMissingException
InvalidFlagArgumentException
UnknownFlagException
FileException
FileNotFoundException
Le 19/02/2012 01:09, Andrei Alexandrescu a écrit :
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 di
On Sat, Feb 18, 2012 at 10:46 PM, H. S. Teoh wrote:
> On Sat, Feb 18, 2012 at 10:21:17PM -0200, Jose Armando Garcia wrote:
>> On Sat, Feb 18, 2012 at 9:13 PM, Andrei Alexandrescu
>> wrote:
>> > On 2/18/12 4:26 PM, Jonathan M Davis wrote (abridged):
>> > GetOptException
>> > FlagArgumentMissingExc
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 frequently using exceptions
incorrectly, and many of the C++ programmers
On Sat, 18 Feb 2012 18:33:01 -0600, Xinok wrote:
While reading "The Right Approach to Exceptions", it gave me this
idea. The user would declare a list of variables of different
types as case statements, and the variable with matches the type
of the switch expression is used.
I don't know how t
On Sat, Feb 18, 2012 at 10:21:17PM -0200, Jose Armando Garcia wrote:
> On Sat, Feb 18, 2012 at 9:13 PM, Andrei Alexandrescu
> wrote:
> > On 2/18/12 4:26 PM, Jonathan M Davis wrote (abridged):
> > GetOptException
> > FlagArgumentMissingException
> > InvalidFlagArgumentException
> > UnknownFlagExcep
On Sat, Feb 18, 2012 at 06:09:30PM -0600, Andrei Alexandrescu wrote:
> On 2/18/12 6:03 PM, Jonathan M Davis wrote:
[...]
> >If we have GetOptException, it should have a variable for which flag failed.
> >Exception doesn't have that. And what if the flag failed because it was
> >given a
> >bad argu
On Saturday, February 18, 2012 16:36:16 H. S. Teoh wrote:
> On Sat, Feb 18, 2012 at 05:13:16PM -0600, Andrei Alexandrescu wrote:
> > On 2/18/12 4:26 PM, Jonathan M Davis wrote (abridged):
> > GetOptException
> > FlagArgumentMissingException
> > InvalidFlagArgumentException
> > UnknownFlagException
While reading "The Right Approach to Exceptions", it gave me this
idea. The user would declare a list of variables of different
types as case statements, and the variable with matches the type
of the switch expression is used.
I don't know how the syntax should look, this is merely an
example
On Sat, Feb 18, 2012 at 05:13:16PM -0600, Andrei Alexandrescu wrote:
> On 2/18/12 4:26 PM, Jonathan M Davis wrote (abridged):
> GetOptException
> FlagArgumentMissingException
> InvalidFlagArgumentException
> UnknownFlagException
> FileException
> FileNotFoundException
> NotFileException
> NotDirExc
On Saturday, February 18, 2012 17:53:52 Andrei Alexandrescu wrote:
> On 2/18/12 5:47 PM, Jakob Ovrum wrote:
> > you are basically arguing against exceptions here
>
> I must have argued my question and point very poorly.
You definitely seem to be arguing for a single Exception type, which does _no
On Saturday, February 18, 2012 18:09:30 Andrei Alexandrescu wrote:
> Of course I can. They call it toString(). The code above pretty much
> proves my point with so much wonderful irony.
How?!! toString doesn't help _at all_. It just gives whatever getopt can come
up with, not what's appropriate f
On Saturday, 18 February 2012 at 23:45:30 UTC, Jacob Carlborg
wrote:
The compiler should try to provide as much information as
possible (that makes sense), anchors, cross-referencing,
inheritance hierarchy, and so on.
Simple patch here:
https://github.com/adamdruppe/dmd/commit/654d39fe17397e0a
On Sat, Feb 18, 2012 at 9:13 PM, Andrei Alexandrescu
wrote:
> On 2/18/12 4:26 PM, Jonathan M Davis wrote (abridged):
> GetOptException
> FlagArgumentMissingException
> InvalidFlagArgumentException
> UnknownFlagException
> FileException
> FileNotFoundException
> NotFileException
> NotDirException
>
On 18/02/2012 23:33, Andrej Mitrovic wrote:
Well it's probably too late to change this behavior. Both the sample
on the hash page and TDPL itself shows the usage of that trick.
That's fine - but let's document it :)
A few things seem to be missing:
- You get a RangeError for reading a nonexis
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 different
exception types?
You mean virtual function
On Saturday, February 18, 2012 17:30:10 Andrei Alexandrescu wrote:
> On 2/18/12 5:20 PM, Jonathan M Davis wrote:
> > On Saturday, February 18, 2012 17:13:16 Andrei Alexandrescu wrote:
> >> On 2/18/12 4:26 PM, Jonathan M Davis wrote (abridged):
> >> GetOptException
> >> FlagArgumentMissingException
1 - 100 of 195 matches
Mail list logo
