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.

And it is horrible. Exceptions were never designed for this. Try benchmarking trivial vibe.d REST service looking up an entry in an array and throwing 404 upon failure. Difference in performanc between "all requests are 200" and "all requests are 404" will be of order of magnitude.

On Friday, 7 February 2014 at 03:14:45 UTC, Sean Kelly wrote:
>>
>> pure @safe void validate(S)(in S str) if (isSomeString!S);
>>
>> Throws:
>> UTFException if str is not well-formed.
>
> And somewhere in the world, darkness fell forever on a bright and beautiful countryside.  The monsters poured forth and devoured everything in sight, given strength by that unbelievable abomination of a function design.

True words indeed!

To sum up this small thread : I am perfectly OK with exceptions not showing in -vgc if we also agree on cleaning up Phobos from control flow exceptions.

On Friday, 7 February 2014 at 05:25:26 UTC, Brad Anderson wrote:
> Thinking about this more it'd probably be a good idea to use the
> type system to segregate non-validated user input from the rest
> of your program. UnvalidatedString or something.
> UnvalidatedString.validate() returns a string you can then use in
> the regular fashion. That way unvalidated data can't weasel its
> way into the trusted portion of your program without getting
> checked first. Anyway, that's just an idea (and getting further
> and further off topic).

Yes, I even had some simple proof-of-concept drafts of such approach for vibe.d but have never finished it. User input is not a problem if Phobos will provide more strongly typed @nothrow tools.

On Friday, 7 February 2014 at 02:42:14 UTC, Walter Bright wrote:
> They're going to be slow when you do it that way.

How slow is slow? Is it slower than in Go and Python? Why would unwinding 8 stack frames be so slow? Is it a language mandated speed issue or just a runtime issue that could be fixed with a compiler switch?

Most of the time is spent waiting for async request from memcaches/databases and other types of network traffic so you usually have some free cycles on a decent CPU. With native code and lightweight threads (coroutines) you should be able to handle 100+ concurrent requests per process.

On Friday, 7 February 2014 at 11:37:16 UTC, Ola Fosheim Grøstad wrote:
> usually have some free cycles on a decent CPU. With native code and lightweight threads (coroutines) you should be able to handle 100+ concurrent requests per process.

When I think of it you could probably just push the RESTException throwing coroutine onto a "delayed request queue" since a timeout on a transaction might be no worse than aborting it (or carry along some kind of context object). That would make DoS less problematic too and you get better latency for good requests and complete the bad requests when you are idle.

On Friday, 7 February 2014 at 11:37:16 UTC, Ola Fosheim Grøstad wrote:
> Is it a language mandated speed issue?

It is assumed by http://dlang.org/errors.html

On Friday, 7 February 2014 at 11:41:43 UTC, Dicebot wrote:
> On Friday, 7 February 2014 at 11:37:16 UTC, Ola Fosheim Grøstad wrote:
>> Is it a language mandated speed issue?
>
> It is assumed by http://dlang.org/errors.html

P.S. Throwing exception is not that slow in D, it is allocating new instance that makes a huge impact.

On Thursday, 6 February 2014 at 22:15:11 UTC, 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.

Hmm... then what _does_ qualify as exceptional in your opinion?

A logic error (i.e. a mistake on the programmers side) doesn't, IMO, it should abort instead. On the other hand, there is the class of situations where e.g. a system call returns an error (say, "permission denied" when opening a file, or out of disk space). Or more generally, an external service, like a database or a remote server. However, I can't see how these are fundamentally different from invalid user input, and indeed, there's often not even a clear separation, e.g. when a user asked you to read a file they don't have access to.

So, what's left then?

On Friday, 7 February 2014 at 14:26:48 UTC, Marc Schütz wrote:
> Hmm... then what _does_ qualify as exceptional in your opinion?
>
> A logic error (i.e. a mistake on the programmers side) doesn't, IMO, it should abort instead. On the other hand, there is the class of situations where e.g. a system call returns an error (say, "permission denied" when opening a file, or out of disk space). Or more generally, an external service, like a database or a remote server. However, I can't see how these are fundamentally different from invalid user input, and indeed, there's often not even a clear separation, e.g. when a user asked you to read a file they don't have access to.
>
> So, what's left then?

It is exceptional situation if input is supposed to be valid but surprisingly is not. For example, calling `decodeGrapheme` on external string without making sure it is valid first. Same goes for file - trying open a missing file is exceptional, but checking for file presence is not.

On Friday, 7 February 2014 at 08:30:35 UTC, Walter Bright wrote:
> On 2/6/2014 7:08 PM, bearophile wrote:
>> That's why some languages have changed their sorting and hashing routines to
>> make them a little slower but safer on default.
>
> DoS attack resistance requires faster code, not slower code.

The specific problem was that it was possible to provoke hash collisions by sending carefully crafted input, causing the hash-tables to degrade to linked lists. The small performance penalty of using collision-resistant hashes is certainly worth it in this case.