Replies: 1 comment
-
Hi @Holf, Yes, that makes sense, I'd be open to a PR. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I have a bit of an edge case and wondered what your thoughts might be, @joshnuss.
This is where the serializer does its stuff when retrieving data from storage:
https://github.com/joshnuss/svelte-local-storage-store/blob/34b1994bd22180d704d7629938e9b27936aa375e/index.ts#L52
Any parsing errors that might occur when the
storage
event fires are unhandled. I wondered if it might be worth catching such errors and adding thekey
name to the error message before rethrowing?As I say, this is quite an edge case; parsing errors should only happen if the value in storage is corrupted in some way, and given the same serializer will have been used to put the data there in the first place, this is unlikely.
But, I'm thinking of a situation where users tamper with storage (on their heads be it!) or if some other (unrelated) code manipulates storage in some way.
I am logging JavaScript errors centrally and, if corruption does occur, it would be useful to know which storage entry is causing the issue. Having the
key
name in the error message would help with this.Beta Was this translation helpful? Give feedback.
All reactions