On 2012-10-01 06:19, Walter Bright wrote:

> Also, consider that in C++ you can throw any type, such as an int. There
> is no credible way to make this work reasonably in D, as exceptions are
> all derived from Exception.

Really, I had not idea that was possible. A workaround could be to convert to a string, wrap it in an exception class and pass to D.

-- 
/Jacob Carlborg

On 2012-10-01 06:35, Andrej Mitrovic wrote:

> Is that a bug or a feature? :)

Actually you can do the same thin in Ruby, at least with strings. This is can be kind of nice, no need to create a new exception type. But in Ruby the string is wrapped in an instance of RuntimeError, so that might not be comparable.

raise "foo"

Is the same as:

raise RuntimeError.new("foo")

-- 
/Jacob Carlborg

On Monday, October 01, 2012 08:14:03 Jacob Carlborg wrote:
> On 2012-10-01 06:19, Walter Bright wrote:
> > Also, consider that in C++ you can throw any type, such as an int. There is no credible way to make this work reasonably in D, as exceptions are all derived from Exception.
> 
> Really, I had not idea that was possible. A workaround could be to convert to a string, wrap it in an exception class and pass to D.

Which would make the exception handling that much mor expensive.

I would think that making it so that proper exception types are handled appropriately is plenty. There are limits to what can be reasonably done (just like at the limits that we have already when dealing with C++ from D). It's already arguably rather stupid to throw anything other than a proper exception type even if the language will let you. At some point, it _will_ be up to the programmer to do the right thing regardless of what level of compatibility we provide.

- Jonathan M Davis

On 27/09/12 15:42, Andrej Mitrovic wrote:
> On 9/27/12, Walter Bright <newshound2@digitalmars.com> wrote:
>> D will probably not bother with the 64 bit SEH.
>
> How come, and what will be the consequences of this?

I don't see much of a reason for this. When I implemented exception chaining, I went to quite a bit of work to understand the 32bit SEH, mostly by reading the 64bit SEH which is a lot nicer and *far* better documented. In most respects it's the same as 32bit SEH but with a lot more restrictions on function calling conventions. The thing I don't know about is how nested functions mesh into the ABI requirements.

Also worth noting that the reason the ABI restrictions exist, is to allow exceptions to cross language barriers.

We should play nice.

On Mon, 01 Oct 2012 08:16:13 +0200
Jacob Carlborg <doob@me.com> wrote:

> On 2012-10-01 06:35, Andrej Mitrovic wrote:
> 
> > Is that a bug or a feature? :)
> 
> Actually you can do the same thin in Ruby, at least with strings. This is can be kind of nice, no need to create a new exception type. But in Ruby the string is wrapped in an instance of RuntimeError, so that might not be comparable.
> 
> raise "foo"
> 
> Is the same as:
> 
> raise RuntimeError.new("foo")
> 

Haxe can throw anything, too. I've always found it borderline useless, and frequently a pain.

On 2012-10-01 14:30, Nick Sabalausky wrote:

> Haxe can throw anything, too. I've always found it borderline useless,
> and frequently a pain.

I find it quite annoying to have to create new classes for exceptions all the time. And since D constructors aren't inherited I need to also create a constructor that just forwards to the base class. Just useless boilerplate code.

-- 
/Jacob Carlborg

On Monday, October 01, 2012 19:14:45 Jacob Carlborg wrote:
> On 2012-10-01 14:30, Nick Sabalausky wrote:
> > Haxe can throw anything, too. I've always found it borderline useless, and frequently a pain.
> 
> I find it quite annoying to have to create new classes for exceptions all the time. And since D constructors aren't inherited I need to also create a constructor that just forwards to the base class. Just useless boilerplate code.

If you really need to declare new exception types all that often, I'd be inclined to think that you're creating a lot of needless exception types. But even if that's not the case and you really need many, new exception types with no extra member variables, it's trivial to create a mixin for doing that, though you don't get any ddoc if you do that.

- Jonathan M Davis

On 2012-10-01 19:23, Jonathan M Davis wrote:

> If you really need to declare new exception types all that often, I'd be
> inclined to think that you're creating a lot of needless exception types. But
> even if that's not the case and you really need many, new exception types with
> no extra member variables, it's trivial to create a mixin for doing that,
> though you don't get any ddoc if you do that.

It's not that many in a single project but I have projects and I prefer to have at least one exception base class in each.

Yeah, mixins and ddoc does not go hand in hand.

-- 
/Jacob Carlborg

On Mon, 01 Oct 2012 19:14:45 +0200
Jacob Carlborg <doob@me.com> wrote:

> On 2012-10-01 14:30, Nick Sabalausky wrote:
> 
> > Haxe can throw anything, too. I've always found it borderline useless, and frequently a pain.
> 
> I find it quite annoying to have to create new classes for exceptions all the time. And since D constructors aren't inherited I need to also create a constructor that just forwards to the base class. Just useless boilerplate code.
> 

If I'm being lazy, I'll just throw a normal Exception:
	throw new Exception("Whatever happened");

So it's almost as convenient as throwing a string (just a little more typing), but unlike throwing strings or other non-Exceptions, you still get the benefits of:

1. Always having the benefits of Exception, such as a stack trace.

2. Never having to deal with, or even consider the possibility of, "What if some stupid lib or callback decides to throw something nonsensical like an int or a Widget?" And a "catch(Exception e)" (or rather "catch(Error e)") will always catch everything. Some languages have a "catch all, from any unspecified type", but then you can't have have any way to access whatever was thrown (unless it's a dynamic language).

But, what you said about Ruby is an interesting idea. Ie, that throwing a string is really just sugar for throwing a normal exception. I didn't know that about Ruby. It would be kinda neat if we could do:

	throw "Shit happened";

And instead of actually throwing a string, it was just sugar for:

	throw new Exception("Shit happened");

That'd be pretty cool.

On a related, but goofier, note: http://semitwist.com/articles/article/view/stupid-coder-tricks-debugging-exception-handlers

On 2012-10-01 22:00, Nick Sabalausky wrote:

> But, what you said about Ruby is an interesting idea. Ie, that throwing
> a string is really just sugar for throwing a normal exception. I didn't
> know that about Ruby. It would be kinda neat if we could do:
>
> 	throw "Shit happened";
>
> And instead of actually throwing a string, it was just sugar for:
>
> 	throw new Exception("Shit happened");
>
> That'd be pretty cool.

Yeah, I wouldn't want this to become a regular String at the catch site, that would be pretty bad.

> On a related, but goofier, note:
> http://semitwist.com/articles/article/view/stupid-coder-tricks-debugging-exception-handlers

That's interesting. But that's also just like creating a function "error" which throws an exception. Which I end up doing sometimes.

-- 
/Jacob Carlborg