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
Better error messages #46
Comments
I am always in favor of more descriptive error messages. If the speed of generating errors is holding back your app, something went wrong long before you chose to use typed-immutable. I do think the JSON should be opt in, since you might be logging a gigantic array of gigantic objects and the rest of your text should help find the error just fine. I don't know if it's the line breaks or if it's longer than I was expecting, but can the message be made more concise? Even if not, I'm in favor. Do you have a PR for it? |
No PR yet, just basic implementation for Maps / Records, need to extend it to other types. It has occurred to me that Union's rely on generating TypeErrors so will need to consider that in final implementation. In terms of size of message it's currently giving you the full trace of each type that failed to instantiate and what the expected type was. Perhaps would be better to just give the path:
The stuff below
|
I would really like this change also. |
After using typed-immutable on multiple projects now the biggest problem that comes up is tracking down why a type error occurs - particularly when restoring a large nested structure from a raw JS object.
As an example:
currently gives an error
This is ok when you have the context and know what structures it's referring to be in many cases you don't or the fields are generic enough that it's hard to identify where it comes from. It's also very useful to know the data that failed.
I've been looking at improving them, eg. the above is now:
My only concern with adding this is that it will be a bit slower to generate this level of detail (eg. doing a
JSON.stringify
on value). In my use cases so far it wouldn't matter as I never catch theTypeError
's - if they occur it's a bug that we fix.Does anyone have any thoughts about this? Should it be opt in? Am I overthinking it? I also haven't measured anything yet - I think it may only become a problem if you were generating a lot of these (eg. iterating a large list attempting to instantiating record's and handling any errors).
@lukesneeringer @stutrek @udnisap
The text was updated successfully, but these errors were encountered: