New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added `throwStubExceptions` option to Meteor.call #4202

Closed
wants to merge 1 commit into
base: devel
from

Conversation

Projects
None yet
5 participants
@tmeasday
Contributor

tmeasday commented Apr 15, 2015

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 Meteor.Errors practically useful for things like validation, we'd like to pass an object as the details field. As documented details is a String, although it works to set it as an arbitrary stringify-able object. Would it make sense to make that official?

Added `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.

@glasser glasser added the Project:DDP label Apr 21, 2015

@glasser

This comment has been minimized.

Member

glasser commented Apr 21, 2015

Thanks, merged!

@glasser glasser closed this in cf24d30 Apr 21, 2015

@tmeasday

This comment has been minimized.

Contributor

tmeasday commented Apr 21, 2015

@glasser: Thanks! - and what do you think about the error.details thing?

@glasser

This comment has been minimized.

Member

glasser commented Apr 21, 2015

Well, that does match the DDP spec, for better or for worse.

@tmeasday

This comment has been minimized.

Contributor

tmeasday commented Apr 22, 2015

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 Meteor.Error, with an error that stringifies its details and somehow de-stringify it manually on the client side?

@glasser

This comment has been minimized.

Member

glasser commented Apr 28, 2015

Sure. Though I mean... I'm not sure where we actually enforce (if anywhere) the details type. We haven't really spent much time on DDP lately.

@zimme

This comment has been minimized.

Contributor

zimme commented Nov 18, 2015

I just had a thought about how this change would allow one to use ObjectId for id's in Meteor, as the stub will run before the call to the method or am I off base?

@scharf

This comment has been minimized.

scharf commented Feb 28, 2017

It would be nice if the throwStubExceptions would be documented as argument for Meteor.apply. I found it in a debug session (wondering how and why the simulation does not throw errors).

@hwillson

This comment has been minimized.

Member

hwillson commented Feb 28, 2017

Good catch @scharf - it is mentioned in the Method call lifecycle section of the Guide, but you're quite right; it should be documented in the API docs. Would you mind opening a new issue about this (to avoid re-opening this older issue)? Thanks!

@scharf

This comment has been minimized.

scharf commented Feb 28, 2017

created a new issue: #8435

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment