On Monday, 25 August 2014 at 15:46:12 UTC, Ola Fosheim Grøstad
wrote:
For a web server it would be most useful to get an exception
since you risk ending up with web-clients not working with no
logging. It is better to have an exception and log an error so
the problem can be fixed.
Let me expand a bit on the difference between web clients and
servers, assuming D is used on the server:
* Web servers have to check all input and log illegal activity.
It is either a bug or an attack.
* Web clients don't have to check input from the server (at most
a crypto check) and should not do double work if servers validate
anyway.
* Web servers detect errors and send the error as a response to
the client that displays it as a warning to the user. This is the
uncommon case so you don't want to burden the client with it.
From this we can infer:
- It makes more sense for ECMAScript to turn illegal values into
null since it runs on the client.
- The server needs efficient validation of input so that it can
have faster response.
- The more integration of validation of typedness you can have in
the parser, the better.
Thus it would be an advantage to be able to configure the
validation done in the parser (through template mechanisms):
1. On write: throw exception on all illegal values or values that
cannot be represented in the format. If the values are illegal
then the client should not receive it. It could cause legal
problems (like wrong prices).
2. On read: add the ability to configure the validation of
typedness on many parameters:
- no nulls, no dicts, only nesting arrays etc
- predetermined key-values and automatic mapping to structs on
exact match.
- require all leaf arrays to be uniform (array of strings, array
of numbers)
- match a predefined grammar
etc
