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
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
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
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
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, 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
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 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 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
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.
Andrei
On 2/18/12 1:41 PM, H. S. Teoh wrote:
On Sat, Feb 18, 2012 at 12:52:05PM -0600, 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 defi
On Saturday, 18 February 2012 at 23:26:14 UTC, Andrei
Alexandrescu wrote:
(b) all real code does one thing.
Andrei
No. It's conceivable that *most* cases simply log the exception
(e.g. by printing it) then either move back or move on (!). But
it's most definitely not *all* and it's when you
Andrei Alexandrescu wrote:
> all real code does one thing
Obviously wrong for operating systems and concurrently searching for a
solution of a problem ... or: how "thing" has to be defined?
-manfred
Le 19/02/2012 00:26, Andrei Alexandrescu a écrit :
On 2/18/12 5:30 PM, deadalnix wrote:
You know that « real life » programming is different than a tutorial.
Problem is (a) all tutorials suggests you have a world of things to do;
(b) all real code does one thing.
Andrei
And usually, one thi
Le 19/02/2012 00:30, Andrei Alexandrescu a écrit :
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
InvalidFlagArgumentException
Unkn
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
InvalidFlagArgumentException
UnknownFlagException
FileException
FileNotFoundException
On 2/18/12 5:30 PM, deadalnix wrote:
You know that « real life » programming is different than a tutorial.
Problem is (a) all tutorials suggests you have a world of things to do;
(b) all real code does one thing.
Andrei
Le 18/02/2012 22:14, Andrei Alexandrescu a écrit :
On 2/18/12 1:27 PM, Alex Rønne Petersen wrote:
Point taken. I suggested GetOptException initially because, based on
usage patterns of std.getopt, it seems to be most common to just catch
the exception (be it a parsing error, type coercion error,
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
> InvalidFlagArgumentException
> UnknownFlagException
> FileException
> FileNotFoundException
> NotFileException
> NotDirExcep
On 2/18/12 4:26 PM, Jonathan M Davis wrote (abridged):
GetOptException
FlagArgumentMissingException
InvalidFlagArgumentException
UnknownFlagException
FileException
FileNotFoundException
NotFileException
NotDirException
AccessDeniedException
I died inside a little.
Andrei
On 18-02-2012 23:35, Timon Gehr wrote:
On 02/18/2012 10:38 PM, Alex Rønne Petersen wrote:
On 18-02-2012 22:30, Timon Gehr wrote:
On 02/18/2012 10:25 PM, Alex Rønne Petersen wrote:
I'd just like to add to this that we don't lose anything per se by
introducing specific exception types. People c
On Saturday, February 18, 2012 20:18:53 Nathan M. Swan wrote:
> Here's a compromise I would suggest: we have the different
> exception types for different exceptional behaviors, but still
> they all descend from a common exception type that has a field
> with the module name; this way, the client c
On 02/18/2012 10:38 PM, Alex Rønne Petersen wrote:
On 18-02-2012 22:30, Timon Gehr wrote:
On 02/18/2012 10:25 PM, Alex Rønne Petersen wrote:
I'd just like to add to this that we don't lose anything per se by
introducing specific exception types. People can still catch Exception
if they really,
On Saturday, February 18, 2012 15:14:04 Andrei Alexandrescu wrote:
> On 2/18/12 1:27 PM, Alex Rønne Petersen wrote:
> > Point taken. I suggested GetOptException initially because, based on
> > usage patterns of std.getopt, it seems to be most common to just catch
> > the exception (be it a parsing
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 exit.
>
> An exemple is std::bad_alloc .
>
On Sat, Feb 18, 2012 at 03:36:40PM -0600, Andrei Alexandrescu wrote:
> On 2/18/12 3:25 PM, Alex Rønne Petersen wrote:
> >I'd just like to add to this that we don't lose anything per se by
> >introducing specific exception types.
>
> 1. Technical debt
I don't understand. Could you elaborate?
> 2
On Sat, Feb 18, 2012 at 10:38:06PM +0100, Alex Rønne Petersen wrote:
> On 18-02-2012 22:30, Timon Gehr wrote:
> >On 02/18/2012 10:25 PM, Alex Rønne Petersen wrote:
> >>
> >>I'd just like to add to this that we don't lose anything per se by
> >>introducing specific exception types. People can still
You don't want to use specific exceptions because it couples unrelated
code. The distinction of recoverable Exceptions and non-recoverable
Errors is good enough in most cases.
Not true, especially in library code. If you try to open a file,
FileNotFoundException should be recoverable, but DiskF
On 18-02-2012 22:30, Timon Gehr wrote:
On 02/18/2012 10:25 PM, Alex Rønne Petersen wrote:
I'd just like to add to this that we don't lose anything per se by
introducing specific exception types. People can still catch Exception
if they really, really want.
We gain executable bloat. I don't k
On 2/18/12 3:25 PM, Alex Rønne Petersen wrote:
I'd just like to add to this that we don't lose anything per se by
introducing specific exception types.
1. Technical debt
2. Set an example that will be followed
3. Boilerplate
Andrei
On 02/18/2012 10:25 PM, Alex Rønne Petersen wrote:
I'd just like to add to this that we don't lose anything per se by
introducing specific exception types. People can still catch Exception
if they really, really want.
We gain executable bloat. I don't know how how significant the amount
woul
On 18-02-2012 21:36, H. S. Teoh wrote:
On Sat, Feb 18, 2012 at 08:20:23PM +0100, deadalnix wrote:
[...]
However, in D, I think this is more the role of an Errors. Exception
are something « softer ». It will alert you on problems your program
encounter, but that are recoverable.
I agree.
[...
H. S. Teoh wrote:
> If you try to open a file, FileNotFoundException should be
> recoverable, but DiskFailureException should not. You need to
> distinguish between them.
this innocent remakr shows in depth that exceptions have a meaning only
under some specific modell. For a program trying to
On 2/18/12 1:27 PM, Alex Rønne Petersen wrote:
Point taken. I suggested GetOptException initially because, based on
usage patterns of std.getopt, it seems to be most common to just catch
the exception (be it a parsing error, type coercion error, or whatever)
and print it.
In fact for the vast m
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
simply forward the ctor call to the base clas
On Sat, Feb 18, 2012 at 08:20:23PM +0100, deadalnix wrote:
[...]
> However, in D, I think this is more the role of an Errors. Exception
> are something « softer ». It will alert you on problems your program
> encounter, but that are recoverable.
I agree.
[...]
> Let's get an exemple : your progr
On Sat, Feb 18, 2012 at 08:18:53PM +0100, Nathan M. Swan wrote:
> On Saturday, 18 February 2012 at 18:52:05 UTC, Andrei Alexandrescu
> wrote:
> >There's a discussion that started in a pull request:
> >
> >https://github.com/alexrp/phobos/commit/4b87dcf39efeb4ddafe8fe99a0ef9a529c0dcaca
> >
> >Let's
On Sat, Feb 18, 2012 at 08:12:43PM +0100, Martin Nowak wrote:
[...]
> Exception are useful for handling unknown errors and probably to
> bundle error handling at a bigger scope.
But the way exceptions are used in D, they are more like errors than
exceptions. The approach in principle is on the rig
On Sat, Feb 18, 2012 at 12:52:05PM -0600, 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.
On Sat, 18 Feb 2012 20:24:16 +0100, deadalnix wrote:
Le 18/02/2012 20:12, Martin Nowak a écrit :
Typed exception being used for local error recovery is about the same as
using
error codes but at a bigger expense. On the plus side exception can
carry more
specific error messages, which could be
On 18-02-2012 20:20, deadalnix wrote:
Le 18/02/2012 19:52, Andrei Alexandrescu a écrit :
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
On Saturday, 18 February 2012 at 18:52:05 UTC, 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
Le 18/02/2012 20:12, Martin Nowak a écrit :
Typed exception being used for local error recovery is about the same as
using
error codes but at a bigger expense. On the plus side exception can
carry more
specific error messages, which could be solved for error codes too.
The problem with error co
Le 18/02/2012 19:52, Andrei Alexandrescu a écrit :
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
On Sat, 18 Feb 2012 19:52:05 +0100, 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 exper
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 submit that catching by type is most
of the time usel
501 - 578 of 578 matches
Mail list logo
