Why is ConvError in std.conv (which is used for to!() on conversion failure) an Error rather than an Exception? I would have expected it to be an Exception. And the fact that it's an Error makes it so that you can't cleanly call to!() and catch an exception on failure and then deal with the fact that it failed. For instance, if it wer an Exception and you had an string which was supposedly an enum value for the enum MyEnum, you could do to!MyEnum(str), catch the Exception on failure, and do whatever was appropriate given that it's not a valid MyEnum. But with it being an Error, you can't do that (unless you're willing to catch an Error which is not supposed to be done). Am I missing something here?

- Jonathan M Davis

Historical reasons. I favor your implied change.

Andrei

On 11/15/10 7:43 PM, Jonathan M Davis wrote:
> Why is ConvError in std.conv (which is used for to!() on conversion failure) an Error rather than an Exception? I would have expected it to be an Exception. And the fact that it's an Error makes it so that you can't cleanly call to!() and catch an exception on failure and then deal with the fact that it failed. For instance, if it wer an Exception and you had an string which was supposedly an enum value for the enum MyEnum, you could do to!MyEnum(str), catch the Exception on failure, and do whatever was appropriate given that it's not a valid MyEnum. But with it being an Error, you can't do that (unless you're willing to catch an Error which is not supposed to be done). Am I missing something here?
>
> - Jonathan M Davis
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

Reminder:  We're supposed to be at least somewhat stable now.  If anyone commits these changes, please put an alias to the old name in std.conv, and deprecate it in a few releases.  While I agree that this is the right decision in the long run, it will break code for me and probably several other people.  The alias will mitigate this.

On 11/15/2010 10:44 PM, Andrei Alexandrescu wrote:
> Historical reasons. I favor your implied change.
>
> Andrei
>
> On 11/15/10 7:43 PM, Jonathan M Davis wrote:
>> Why is ConvError in std.conv (which is used for to!() on conversion
>> failure) an
>> Error rather than an Exception? I would have expected it to be an
>> Exception. And
>> the fact that it's an Error makes it so that you can't cleanly call
>> to!() and
>> catch an exception on failure and then deal with the fact that it
>> failed. For
>> instance, if it wer an Exception and you had an string which was
>> supposedly an
>> enum value for the enum MyEnum, you could do to!MyEnum(str), catch
>> the Exception
>> on failure, and do whatever was appropriate given that it's not a
>> valid MyEnum.
>> But with it being an Error, you can't do that (unless you're willing
>> to catch an
>> Error which is not supposed to be done). Am I missing something here?
>>
>> - Jonathan M Davis
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>

On Monday 15 November 2010 19:44:50 Andrei Alexandrescu wrote:
> Historical reasons. I favor your implied change.

Enhancement request created: http://d.puremagic.com/issues/show_bug.cgi?id=5220

Hopefully someone with write access can get around to it before the next release - particularly since it should be a very quick and simple change. In either case, this way it won't be forgotten.

- Jonathan M Davis

Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> On Monday 15 November 2010 19:44:50 Andrei Alexandrescu wrote:
> > Historical reasons. I favor your implied change.
> 
> Enhancement request created: http://d.puremagic.com/issues/show_bug.cgi?id=5220
> 
> Hopefully someone with write access can get around to it before the next release - particularly since it should be a very quick and simple change. In either case, this way it won't be forgotten.

Okay, replaced all ConvError with ConvException.

By the way, it feels redundant for me to name every exception class with an ending Exception, especially descriptive ones such as ConvOverflowException.  Couldn't it be ConversionOverflow?


Shin

On Tuesday 16 November 2010 12:41:29 Shin Fujishiro wrote:
> Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> > On Monday 15 November 2010 19:44:50 Andrei Alexandrescu wrote:
> > > Historical reasons. I favor your implied change.
> > 
> > Enhancement request created: http://d.puremagic.com/issues/show_bug.cgi?id=5220
> > 
> > Hopefully someone with write access can get around to it before the next release - particularly since it should be a very quick and simple change. In either case, this way it won't be forgotten.
> 
> Okay, replaced all ConvError with ConvException.
> 
> By the way, it feels redundant for me to name every exception class with an ending Exception, especially descriptive ones such as ConvOverflowException.  Couldn't it be ConversionOverflow?

It's clearer and more consistent to have Exception in the name. It makes it nice and obvious that you're dealing with an exception type, and it's not like youe have to type them very often anyway. Also, what would you do for stuff like std.datetime? It has DateTimeException. It's not like you can change it to DateTime. Not only would that be a bad name (since its name is not indicative of an exception or error at all), but there's already a separate DateTime type.

FWIW, all of the exceptions in Java have Exception in their name, and as far as I recall, every exception class that I've used in any other language has had Exception or exception in its name. It makes it nice and clear that you're dealing with an exception type, and while some might be able leave it out - like ConversionOverflow - that leads to inconsistency with all of the exception types which need it in order to make it clear that they're actually an error of some sort.

So, I definitely think that in Phobos and Druntime we should have Exception as the suffix for all Throwables descended from Exception and Error as the suffix for all Throwables descended from Error. It's clear and consistent that way.

- Jonathan M Davis

Once again, *please* put the aliases in for the old names for a few releases.  I'm getting really, really sick of having my code break every release now that D2 is supposed to be "stable" and I think other D users are starting to feel the same way.

On Tue, Nov 16, 2010 at 4:00 PM, Jonathan M Davis <jmdavisProg at gmx.com>wrote:

> On Tuesday 16 November 2010 12:41:29 Shin Fujishiro wrote:
> > Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> > > On Monday 15 November 2010 19:44:50 Andrei Alexandrescu wrote:
> > > > Historical reasons. I favor your implied change.
> > >
> > > Enhancement request created: http://d.puremagic.com/issues/show_bug.cgi?id=5220
> > >
> > > Hopefully someone with write access can get around to it before the
> next
> > > release - particularly since it should be a very quick and simple change. In either case, this way it won't be forgotten.
> >
> > Okay, replaced all ConvError with ConvException.
> >
> > By the way, it feels redundant for me to name every exception class with an ending Exception, especially descriptive ones such as ConvOverflowException.  Couldn't it be ConversionOverflow?
>
> It's clearer and more consistent to have Exception in the name. It makes it
> nice
> and obvious that you're dealing with an exception type, and it's not like
> youe
> have to type them very often anyway. Also, what would you do for stuff like
> std.datetime? It has DateTimeException. It's not like you can change it to
> DateTime. Not only would that be a bad name (since its name is not
> indicative of
> an exception or error at all), but there's already a separate DateTime
> type.
>
> FWIW, all of the exceptions in Java have Exception in their name, and as
> far as
> I recall, every exception class that I've used in any other language has
> had
> Exception or exception in its name. It makes it nice and clear that you're
> dealing with an exception type, and while some might be able leave it out -
> like
> ConversionOverflow - that leads to inconsistency with all of the exception
> types
> which need it in order to make it clear that they're actually an error of
> some
> sort.
>
> So, I definitely think that in Phobos and Druntime we should have Exception
> as
> the suffix for all Throwables descended from Exception and Error as the
> suffix for
> all Throwables descended from Error. It's clear and consistent that way.
>
> - Jonathan M Davis
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20101116/87c89919/attachment-0001.html>

David Simcha <dsimcha at gmail.com> wrote:
> Once again, *please* put the aliases in for the old names for a few releases.  I'm getting really, really sick of having my code break every release now that D2 is supposed to be "stable" and I think other D users are starting to feel the same way.

As for ConvException and ConvOverflowException, I did put the aliases.


Shin

Oh, sorry, didn't notice.

On Tue, Nov 16, 2010 at 4:13 PM, Shin Fujishiro <rsinfu at gmail.com> wrote:

> David Simcha <dsimcha at gmail.com> wrote:
> > Once again, *please* put the aliases in for the old names for a few releases.  I'm getting really, really sick of having my code break every release now that D2 is supposed to be "stable" and I think other D users
> are
> > starting to feel the same way.
>
> As for ConvException and ConvOverflowException, I did put the aliases.
>
>
> Shin
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20101116/574e1ca6/attachment.html>

Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> On Tuesday 16 November 2010 12:41:29 Shin Fujishiro wrote:
> > By the way, it feels redundant for me to name every exception class with an ending Exception, especially descriptive ones such as ConvOverflowException.  Couldn't it be ConversionOverflow?
> 
> It's clearer and more consistent to have Exception in the name. It makes it nice and obvious that you're dealing with an exception type, and it's not like youe have to type them very often anyway. Also, what would you do for stuff like std.datetime? It has DateTimeException. It's not like you can change it to DateTime. Not only would that be a bad name (since its name is not indicative of an exception or error at all), but there's already a separate DateTime type.
> 
> FWIW, all of the exceptions in Java have Exception in their name, and as far as I recall, every exception class that I've used in any other language has had Exception or exception in its name. It makes it nice and clear that you're dealing with an exception type, and while some might be able leave it out - like ConversionOverflow - that leads to inconsistency with all of the exception types which need it in order to make it clear that they're actually an error of some sort.
> 
> So, I definitely think that in Phobos and Druntime we should have Exception as the suffix for all Throwables descended from Exception and Error as the suffix for all Throwables descended from Error. It's clear and consistent that way.

Yeah, I agree that suffixed Exceptions are very clear.  I wrote it because std.concurrency has non-suffixed exceptions such as MessageMismatch, which are still clear thanks to negative terms embedded in their names.


Shin