Update docs with fetchOne and fetchValue

[robfallows]

LOL. Yes, they are! Well spotted. I should get some sleep ... but I'll update the PR first :wink:

[rclai]

Lol, isn't it like 3 pm or something in UK?

[robfallows]

Yeah - but lots of late nights are catching up.

[stubailo]

Is there some way we can list the exceptions such that we can change the error message later? Like if we could have a separate error code and message or something.

[robfallows]

I was thinking the same thing, but we'd need a systematic way of assigning numbers ... is there already one within Meteor (I thought error numbers had been deprecated in favour of strings)?

[robfallows]

Or are you thinking more along the lines of an array of error messages, which the code reports from via an index number?

[stubailo]

Well with Meteor.Error you can pass an error and reason field like this: new Meteor.Error("must-be-select-query", "Can only call fetch/fetchOne/fetchValue on select queries.")

The problem is that Meteor.Error data is exposed to the client. Do Node/JavaScript Error objects have something similar?

[robfallows]

The standard JS Error object has name and message properties, which seem to have a 1:1 correspondence with error and reason.

[stubailo]

Great - so let's do that. I'd like to reserve the option to change the long error message later without breaking everything.

[stubailo]

I guess this actually requires a change to the implementation of the feature, not just the docs! But I think it'll be a good thing to do.

[robfallows]

So, you actually said "error code", so it obviously doesn't need to be a number (my mistake). However, we'd still to agree on a convention for error codes - more so if this was to extend out elsewhere into Meteor core.

[robfallows]

You need a consistent convention for codes, because it simplifies diagnosis and testing ... "Oh, it's a PGE code - so it's a Postgres error" ... that sort of thing.

[stubailo]

I think we can do this incrementally - I'm pretty sure error strings are already a lot better than specific error numbers which are much much better than generic numbers like "503". Let's not block improving our error codes on a wide-ranging strategic decision about the ecosystem.

[robfallows]

LOL. Okay - I'll make a change and we'll see where that takes us.

[robfallows]

First pass with new exception names and messages.

[robfallows]

@rclai , @stubailo : All sounds highly sensible to me. We're saying that exceptions should be reserved for usage issues only?

[stubailo]

@robfallows I guess the idea is exceptions shouldn't arise from different runtime conditions or data, but only from actual errors in code? It depends on if you look at exceptions as a debugging aid, or a thing you expect to happen at runtime. I think in JavaScript exceptions aren't often used as a thing that pops up in runtime, since it can be hard to figure out the scope of possible exceptions for a certain method.

[stubailo]

Works for me!

Also, you have a super weird style for comments where the // is immediately after the line, and the rest is indented - do you have some tool for that?

[robfallows]

Haha - why thank you :smile:

It's a compromise of my many bizarre requirements.

I tend to use docblock style at "the top" of a class or library to explain the "what" and perhaps the "why". Within the code I like to keep the "how" as in-line comments to allow as much code as possible on a page. However, closely aligned annotation is very hard to read, so I like to maintain a constant position for the left hand side of the comments. This means it's very easy to scan the comments and get a feel for what's going on in the code without the distraction of the code getting in the way. The reason the // characters are placed where they are is thanks to the "code prettifying" in Sublime, which drags them there. So now I do it automatically.

I understand it's not to everyone's taste, but you did ask! :wink:

[stubailo]

Yeah I'm not a big fan to be honest but a good contribution is a good contribution!