throwStubExceptions option to Meteor.call
Allows method simulations to be used as validators and enables freely throwing exceptions in method definitions without worrying about spurious logging on the client.
The motivation for this is to allow a solution to one of the problems outlined here: https://meteor.hackpad.com/Separating-call-into-call-and-callAsync-kNjhay2PLlM
I realise a better solution is probably warranted but this allows workarounds.
A related question: To actually make throwing
The fact that it is a string matches the DDP spec?
So if I'm understanding this right -- if I put an object in there, although it works, I'm actually making Meteor not follow spec (it ends up sending an object over DDP), and thus it's quite conceivable if you tighten things up this will end up no longer working.
I take it changing the DDP spec is a PITA. Does this mean our best bet here is to wrap