On Fri, Mar 10, 2017 at 3:29 AM, Sam Duke <[email protected]> wrote:
> Is it not that case that displaying or using default values as if they are > truth is not always appropriate/safe? > IMO, it's not the server's job to verify that the message sent by the client is really exactly what the client intended. Sure, the server can do some sanity checks, but this should be limited to what is reasonable. Ultimately only the client can ensure that its own code is correct. > Having a potential 'default' flow through an application also creates > additional work/thought to make sure it is still 'safe' or appropriate (and > you need to think of all the combinations of default values that might > occur). > No: If the default value is within the range of values that the client might reasonably have specified, then it should be no additional work to handle the default, because it's a value you had to handle anyway. Think of it this way. If I say that the default value for `foo` is 0, then when the client actually wants to send `foo = 0`, it has two different ways to do this: it can call `setFoo(0)`; or it can skip calling `setFoo()` altogether. This is up to the client and its programmer. When the server receives the message, it should assume that `foo = 0` is in fact what the client intended. > The "fail fast, fail early" philosophy is, IMHO, a safer approach. > (hopefully it's clear this is just my current opinion and I'm not trying to > say you are wrong, just maybe looking from the POV of a different type of > application). > Catching errors early is certainly nice, but we need to recognize that there are an infinite number of errors you can check for, and another infinite number of errors that you simply can't check for, or can't reasonably check for. So, you can't check everything and have to do some triage. I'd say check for the errors that have a high value of F*S/C, where F = frequency with which programmers are likely to make the error, S = severity of the damage caused by such an error if not caught (e.g. will it corrupt stored data? or will it just cause an exception to be thrown a bit later in the proceduce?), and C = cost of checking for the error (where bloating the size of every message would be a high cost). -Kenton -- You received this message because you are subscribed to the Google Groups "Cap'n Proto" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/group/capnproto.
