ZippyJSON doesn't throw errors until after a value has been unboxed, which means you can't use "try?" effectively about zippyjson HOT 4 CLOSED

Put up an initial PR at #13, let me know what you think!

from zippyjson.

I am curious though: do you control the JSON coming in that can be one of two types for that key? If so, I would recommend using different keys for those types. I also would imagine that it's pretty expensive performance-wise to be throwing exceptions, and that that cost might even dominate the library parsing.

from zippyjson.

Unfortunately we don't control this JSON :(

From a parsing perspective, I do agree that it would probably be strictly faster to use different keys, but performance-wise I'm not completely sure what the hit would be - I was under the impression that because of how Swift error handling works, throwing an error has about the same cost as a return.

I profiled the performance for our use case with Apple's JSONDecoder (though haven't run the benchmarks listed in #13 yet) - for the case I profiled we have something like 400,000 objects with a String property which is converted from either a String or Number json type, and about 94% of the CPU time was spent doing bridging to NSDictionary, which makes me hopeful that even with error throwing, ZippyJSON could be significantly faster for our use case.

I'm going to play around with the benchmarks you mentioned in #13 today (thanks for the help there!) and see what effects this error throwing has

from zippyjson.

Done in v1.1.0

from zippyjson.