On Thu, 06 Feb 2014 14:08:39 -0500, Adam D. Ruppe <destructionator@gmail.com> wrote:

> On Thursday, 6 February 2014 at 18:52:21 UTC, fra wrote:
>> Hey, wait a second. How do you throw without allocating?
>
> I think exceptions should be ok. You optimize the typical path, and exceptions are (by definition) an exceptional path. If they are also unacceptable, you could restrict yourself to nothrow functions. (Which can still throw Errors... but meh they are even *more* exceptional)

I think if reference counting is added, exceptions would be a prime candidate for using it. They are basically discarded immediately after being handled.

-Steve

On 2/6/2014 11:54 AM, Sean Kelly wrote:
> Does this case even matter?  Exceptions are not a normal function of execution,
> and so should happen rarely to never.  And it's a time when I'd expect a delay
> anyway.

Right. If you're:

1. using throws as control flow logic

2. requiring a throw in a performance critical loop to be performance critical

3. doing so many throws that the garbage collector needs to run to clean them up

you're doing it wrong.

I'm tempted to say that the throw expression can call 'new' even if the function is marked as @nogc.

On Friday, 7 February 2014 at 01:23:44 UTC, Walter Bright wrote:
> Right. If you're:
>
> 1. using throws as control flow logic
[...]
> you're doing it wrong.

I disagree.

REST based web services tend to use throws all the time. It is a an effective and clean way to break all transactions that are in progress throughout the call chain when you cannot carry through a request, or if the request returns nothing.

On 2/6/14, 5:23 PM, Walter Bright wrote:
> I'm tempted to say that the throw expression can call 'new' even if the
> function is marked as @nogc.

That's extreme. A better possibility is to allocate exceptions from a different heap and proclaim that the heap is cleaned once all catch blocks are left. (I'm sure we can find something better, but now is not the time to worry about it.)

Andrei

On Friday, 7 February 2014 at 01:31:17 UTC, Ola Fosheim Grøstad
wrote:
> On Friday, 7 February 2014 at 01:23:44 UTC, Walter Bright wrote:
>> Right. If you're:
>>
>> 1. using throws as control flow logic
> [...]
>> you're doing it wrong.
>
> I disagree.
>
> REST based web services tend to use throws all the time. It is a an effective and clean way to break all transactions that are in progress throughout the call chain when you cannot carry through a request, or if the request returns nothing.

I think in the case of people using exceptions for control flow a GC.free in your exception handler would suffice for preventing the GC heap from growing to
the point where collection times become a concern.

On Friday, 7 February 2014 at 02:19:42 UTC, Andrei Alexandrescu wrote:
> A better possibility is to allocate exceptions from a different heap and proclaim that the heap is cleaned once all catch blocks are left.

I wrote a quick proof of concept of this that can be tested right now:
http://arsdnet.net/dcode/except.d

It hooks _d_newclass to allocate Throwables on a little static bump-the-pointer array. Each catch block has a scope(success) in it that zeroes the throwables area back out to zero.

On 2/6/2014 5:31 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Friday, 7 February 2014 at 01:23:44 UTC, Walter Bright wrote:
>> Right. If you're:
>>
>> 1. using throws as control flow logic
> [...]
>> you're doing it wrong.
>
> I disagree.
>
> REST based web services tend to use throws all the time. It is a an effective
> and clean way to break all transactions that are in progress throughout the call
> chain when you cannot carry through a request, or if the request returns nothing.

They're going to be slow when you do it that way.

On 2/6/2014 2:15 PM, Brad Anderson wrote:
> Personally I don't think bad user input qualifies as an exceptional case because
> it's expected to happen and the program is expected to handle it (and let the
> user know) when it does. That's just a matter of taste though.

It's not a matter of taste. If your input is subject to a DoS attack, don't put exceptions in the control flow.

Walter Bright:

> It's not a matter of taste. If your input is subject to a DoS attack, don't put exceptions in the control flow.

Perhaps the world of today malicious attacks on the software you write should be assumed as the default situation, and then the language+library has to offer something less paranoiac on request.

That's why some languages have changed their sorting and hashing routines to make them a little slower but safer on default.

Bye,
bearophile

On Thursday, 6 February 2014 at 21:48:13 UTC, Dicebot wrote:
> On Thursday, 6 February 2014 at 19:54:27 UTC, Sean Kelly wrote:
>> Does this case even matter?  Exceptions are not a normal function of execution, and so should happen rarely to never.  And it's a time when I'd expect a delay anyway.
>
> Imagine intentionally crafted broken utf as user input in repeated requests. You don't have control over it.
>
> Now if Phobos would have only thrown exceptions in really _exceptional_ situations and handled broken input gracefully...

That's a tough one.  Bad input typically shouldn't generate an exception, but sometimes doing so is handy from a flow control perspective (I know I know, exceptions aren't for flow control).  In the few instances where I use an exception for flow control though (like core.demangle) I always use a static instance, so no allocation occurs, and it's entirely internal to the routine.

I think it's fair to say that _an_API_ shouldn't allocate and throw an exception to indicate an expected error condition.  For a parser, invalid input definitely applies.  So then if the user wants to throw an exception in that case, they can do so themselves.  Then the choice of allocation is left to the user, not imposed on them.  It's generally really easy to let the user supply a delegate to execute on error too, so they don't even necessarily have to check a return code.