On 29/09/2014 20:28, Sean Kelly wrote:
Checked exceptions are good in theory but they failed utterly in
Java. I'm not interested in seeing them in D.
That is the conventional theory, the established wisdom.
But the more I become experienced with Java, over the years, I've become
convinced oth
On Wed, Oct 1, 2014 at 7:24 AM, Bruno Medeiros via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
>
> What has failed is not the concept of checked exceptions per se, but
> mostly, the failure of Java programmers to use checked exceptions
> effectively, and properly design their code around t
On Wednesday, 1 October 2014 at 22:42:27 UTC, Jeremy Powers via
Digitalmars-d wrote:
If you see "throws Exception" in java code chances are the code
is broken,
same as if you see "catch (Exception" - this tells you nothing
about the
exception that happened, and hence you can do nothing with it
On Wednesday, 1 October 2014 at 23:00:41 UTC, Sean Kelly wrote:
...while in Phobos, most of the subtyped exceptions were
eliminated a while back in favor of just always throwing
Exception.
What are you referring to specifically? Compared to Tango, yes,
Phobos might have a lot fewer concrete ex
On 10/1/14, 4:00 PM, Sean Kelly wrote:
On Wednesday, 1 October 2014 at 22:42:27 UTC, Jeremy Powers via
Digitalmars-d wrote:
If you see "throws Exception" in java code chances are the code is
broken,
same as if you see "catch (Exception" - this tells you nothing about the
exception that happened
On 02/10/14 01:19, David Nadlinger wrote:
What are you referring to specifically? Compared to Tango, yes, Phobos
might have a lot fewer concrete exception types. But I don't recall
actually eliminating existing ones.
It happens implicitly when using "enforce". By default it will throw an
inst
On 02/10/14 01:19, Andrei Alexandrescu wrote:
My recollection is that was only talked about. Anyhow, one thing is
clear - as of now there are no clear idioms and successful techniques
for handling errors with exceptions (including the use of subtyping). --
Andrei
I think most error handling is
On Thursday, 2 October 2014 at 06:39:17 UTC, Jacob Carlborg wrote:
On 02/10/14 01:19, David Nadlinger wrote:
What are you referring to specifically? Compared to Tango,
yes, Phobos
might have a lot fewer concrete exception types. But I don't
recall actually eliminating existing ones.
It happe
On 2014-10-03 14:36, David Nadlinger wrote:
you are saying that specific exceptions were replaced by enforce? I
can't recall something like this happening.
I have no idea about this but I know there are a lot of "enforce" in
Phobos and it sees to be encouraged to use it. Would be really sad i
Am Fri, 03 Oct 2014 21:35:01 +0200
schrieb Jacob Carlborg :
> On 2014-10-03 14:36, David Nadlinger wrote:
>
> > you are saying that specific exceptions were replaced by enforce? I
> > can't recall something like this happening.
>
> I have no idea about this but I know there are a lot of "enforce
On 10/5/14, 8:08 AM, Marco Leise wrote:
Nice, finally someone who actually wants to discern Exception
types. I'm always at a loss as to what warrants its own
exception type. E.g. when looking at network protocols, would
a 503 be a NetworkException, a HTTPException or a
HTTPInternalServerErrorExce
On 2014-10-05 17:08, Marco Leise wrote:
Nice, finally someone who actually wants to discern Exception
types. I'm always at a loss as to what warrants its own
exception type.
Yeah, that can be quite difficult. In the end, if you have a good
exception hierarchy I don't think it will hurt to hav
On 10/5/14, 8:56 AM, Jacob Carlborg wrote:
I would like to have as specific exception type as possible. Also a nice
hierarchy of exception when catching a specific exception is not
interesting. Instead of just a FileException there could be
FileNotFoundException, PermissionDeniedExcepton and so o
On Sunday, 5 October 2014 at 16:18:33 UTC, Andrei Alexandrescu
wrote:
On 10/5/14, 8:56 AM, Jacob Carlborg wrote:
I would like to have as specific exception type as possible.
Also a nice
hierarchy of exception when catching a specific exception is
not
interesting. Instead of just a FileExceptio
On 10/5/2014 9:18 AM, Andrei Alexandrescu wrote:
Exceptions are all about centralized error handling. How, and how often, would
you handle FileNotFoundException differently than PermissionDeniedException?
You would handle it differently if there was extra data attached to that
particular excep
05-Oct-2014 20:18, Andrei Alexandrescu пишет:
On 10/5/14, 8:56 AM, Jacob Carlborg wrote:
I would like to have as specific exception type as possible. Also a nice
hierarchy of exception when catching a specific exception is not
interesting. Instead of just a FileException there could be
FileNotFo
On 10/5/14, 2:27 PM, Walter Bright wrote:
On 10/5/2014 9:18 AM, Andrei Alexandrescu wrote:
Exceptions are all about centralized error handling. How, and how
often, would
you handle FileNotFoundException differently than
PermissionDeniedException?
You would handle it differently if there was ex
On 05/10/14 23:50, Dmitry Olshansky wrote:
Seems like it should be possible to define multiple interfaces for
exceptions, and then catch by that (and/or combinations of such).
Each of interface would be interested in a particular property of
exception. Then catching by:
FileException with Perm
On 05/10/14 18:18, Andrei Alexandrescu wrote:
Exceptions are all about centralized error handling. How, and how often,
would you handle FileNotFoundException differently than
PermissionDeniedException?
Probably not that often. But I don't think it's up to "File" to decide
that. I think "File"
06-Oct-2014 10:33, Jacob Carlborg пишет:
On 05/10/14 23:50, Dmitry Olshansky wrote:
Seems like it should be possible to define multiple interfaces for
exceptions, and then catch by that (and/or combinations of such).
Each of interface would be interested in a particular property of
exception.
On 10/5/14, 11:31 PM, Jacob Carlborg wrote:
On 05/10/14 18:18, Andrei Alexandrescu wrote:
Exceptions are all about centralized error handling. How, and how often,
would you handle FileNotFoundException differently than
PermissionDeniedException?
Probably not that often. But I don't think it's
On 10/5/14, 11:39 PM, Dmitry Olshansky wrote:
It's obvious to me that one hierarchy is way to limiting for exceptions,
simply because there could be many ways to categorize the same set of
error conditions.
Well put. -- Andrei
On Mon, Oct 06, 2014 at 06:46:31AM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
> On 10/5/14, 11:39 PM, Dmitry Olshansky wrote:
> >
> >It's obvious to me that one hierarchy is way to limiting for
> >exceptions, simply because there could be many ways to categorize the
> >same set of error c
On 10/6/14, 7:01 AM, H. S. Teoh via Digitalmars-d wrote:
On Mon, Oct 06, 2014 at 06:46:31AM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
On 10/5/14, 11:39 PM, Dmitry Olshansky wrote:
It's obvious to me that one hierarchy is way to limiting for
exceptions, simply because there could be
On 06/10/14 15:45, Andrei Alexandrescu wrote:
Knowledge doesn't have to be by type; just place data inside the
exception. About the only place where multiple "catch" statements are
used to make fine distinctions between exception types is in sample code
showing how to use multiple "catch" statem
On 10/6/14, 7:48 AM, Jacob Carlborg wrote:
On 06/10/14 15:45, Andrei Alexandrescu wrote:
Knowledge doesn't have to be by type; just place data inside the
exception. About the only place where multiple "catch" statements are
used to make fine distinctions between exception types is in sample cod
On Mon, 06 Oct 2014 15:48:31 +0100, Jacob Carlborg wrote:
On 06/10/14 15:45, Andrei Alexandrescu wrote:
Knowledge doesn't have to be by type; just place data inside the
exception. About the only place where multiple "catch" statements are
used to make fine distinctions between exception types
On 2014-10-06 17:07, Andrei Alexandrescu wrote:
I don't. On the contrary, I do consider proliferating types to the
multiplicity of possible errors an obvious design sin. -- Andrei
You loose the ability to have exception specific data. And no, I don't
want to see an associative array of Varian
On 2014-10-06 18:03, Regan Heath wrote:
Why?
It gives us the benefits of error code return values:
- ability to easily/cheaply check for/compare them using "switch" on
code value (vs comparing/casting types)
- ability to pass through OS level codes directly
Without any of the penalties:
Jacob Carlborg wrote:
> On 2014-10-06 17:07, Andrei Alexandrescu wrote:
>
>> I don't. On the contrary, I do consider proliferating types to the
>> multiplicity of possible errors an obvious design sin. -- Andrei
>
> You loose the ability to have exception specific data. And no, I don't
> want to
On 10/6/14, 11:13 AM, Jacob Carlborg wrote:
Then you'll always catch all exceptions. If error code doesn't match you
need to rethrow the exception. Or make a language change that allows to
catch based on the error code.
Either solution is fine here because that's the rare case. -- Andrei
On Mon, Oct 6, 2014 at 7:50 AM, Andrei Alexandrescu via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On 10/6/14, 7:01 AM, H. S. Teoh via Digitalmars-d wrote:
>
>> On Mon, Oct 06, 2014 at 06:46:31AM -0700, Andrei Alexandrescu via
>> Digitalmars-d wrote:
>>
>>> On 10/5/14, 11:39 PM, Dmitry
On 10/6/14, 4:46 PM, Jeremy Powers via Digitalmars-d wrote:
On Mon, Oct 6, 2014 at 7:50 AM, Andrei Alexandrescu via Digitalmars-d
I'm thinking a simple key-value store Variant[string] would
accommodate any state needed for differentiating among exception
kinds whenever that's necessar
On 06/10/14 20:26, Andrei Alexandrescu wrote:
Then scope them.
We already have scoping rules built in to the language. Why should we
invent a new way and set of rules for this.
--
/Jacob Carlborg
On Mon, Oct 6, 2014 at 6:19 PM, Andrei Alexandrescu via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On 10/6/14, 4:46 PM, Jeremy Powers via Digitalmars-d wrote:
>
>> On Mon, Oct 6, 2014 at 7:50 AM, Andrei Alexandrescu via Digitalmars-d
>> I'm thinking a simple key-value store Variant[
On Mon, Oct 6, 2014 at 6:19 PM, Andrei Alexandrescu via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On 10/6/14, 4:46 PM, Jeremy Powers via Digitalmars-d wrote:
>
>> On Mon, Oct 6, 2014 at 7:50 AM, Andrei Alexandrescu via Digitalmars-d
>> I'm thinking a simple key-value store Variant[
On Tue, Oct 07, 2014 at 02:25:24PM -0700, Jeremy Powers via Digitalmars-d wrote:
> On Mon, Oct 6, 2014 at 6:19 PM, Andrei Alexandrescu via Digitalmars-d <
> digitalmars-d@puremagic.com> wrote:
>
> > On 10/6/14, 4:46 PM, Jeremy Powers via Digitalmars-d wrote:
> >
> >> On Mon, Oct 6, 2014 at 7:50 AM
On Tue, Oct 7, 2014 at 3:44 PM, H. S. Teoh via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
[snip a bunch of stuff where we totally agree with each other]
> Having said all that, though, an idea occurred to me. While it's
> certainly true that the catch block must catch a *specific* type
On Tue, Oct 07, 2014 at 04:14:57PM -0700, Jeremy Powers via Digitalmars-d wrote:
> On Tue, Oct 7, 2014 at 3:44 PM, H. S. Teoh via Digitalmars-d <
> digitalmars-d@puremagic.com> wrote:
[...]
> > But what if we allow catch blocks to be "templated"?
> >
> > We could then introduce signature constraint
39 matches
Mail list logo
