Added methods that throw errors if the type is not what is expected.

[hollyschilling]

This extension is useful for non-optional properties in a failable initializer. For example:

class Foo {
    var one : String = ""
    var two : Int = 0
    var optionalFloat : Float? 

    init?(json : JSON) {
        do {
            one = try json["one"].requiredString()
            two = try json["two"].requiredInt()
        } catch {
            return nil
        }
        optionalFloat = json["optionalFloat"].float
    }
} 

[jkubicek]

I'm strongly in favor if this, I think it's a great addition.

What would you say to removing "required" from the method names? It would fit with the existing SwiftyJSON naming conventions. Also, I think the type signature (func string() throws -> String) implies that the property would be required.

[charlag]

I would love to use this!

[CosynPa]

@jkubicek I think this is confusing since we already have string property.

[CosynPa]

I think it's better to use the rawString, rawArray series API instead of the stringValue, arrayValue API to implement these methods. And I wish requiredDictionaryObject which returns [String: AnyObject] and requiredArrayObject which returns [AnyObject] are added too.

[CosynPa]

And requiredBool is a must, since boolean type is different type from number type.

[zhigang1992]

Looks interesting, can you kindly add a bit of test and update the syntax to swift3.
Would love to ship this.

Also, sorry for not getting to this sooner.

[ldiqual]

@zhigang1992 Looking at the code, it seems that we're gonna end up with a confusing API. For instance, to unpack a string you have

• json.string -> String?
• json.stringValue -> String with a fallback on "" if not found, potentially error prone
• json.requiredString throws -> String which throws if the value is incorrect.

I would argue that we should be as strict as possible and leave the responsibility on the user to fallback on whatever is best if the value cannot be unpacked. This is why I'm proposing this unique interface:

• json.string() throws -> String

It covers all the cases above:

• try? json.string()
• try? json.string() ?? ""
• try json.string()

It also has the value to provide an explicit error if the unpack fail, as opposed to returning nil or a "fake" value. Imho it'll lead to more robustness in codebases.

However it does introduce a code-breaking change, probably worth a SwiftyJSON v4 or something. What do you think?

[CosynPa]

@ldiqual This change is huge, but the benefit is not that much. I don't think the try syntax is very beginner friendly or easy to use.

[hollyschilling]

I must admit I all but forgot about this pull request.

Although there could still be uses of this type of functionality in SwiftyJSON, my specific use case was abusing the library. As such, I built a component in my BetterLibrary that is better designed for my purpose. It is available as a Cocoapod or through SPM. It is fairly mature now, but I would love to have more eyes on it.

[kszuba]

You should consider add @hollyschilling code or add something like tryString, because good mapping in reactive base project (like RxSwift) practically base on try!

I don't think the try syntax is very beginner friendly or easy to use

@CosynPa If someone use this pod and new "not beginner friendly" func / var with try in extension is a problem, then this someone will learn how to use try catch 🥇

PS. @hollyschilling BetterLibrary, really good work :)

[Kalzem]

any news on making SwiftyJSON throwable?

[kszuba]

@BabyAzerty
I created new pod JSONModel with throwable extension. I can share it for you, but IMO the best option for throwable mapping is use:
https://hackernoon.com/everything-about-codable-in-swift-4-97d0e18a2999
https://github.com/quicktype/quicktype-xcode?utm_campaign=iOS%2BDev%2BWeekly&utm_medium=email&utm_source=iOS_Dev_Weekly_Issue_333

Read this article and check pod. If you will still need SwiftyJSON with throwable extension then mention me and I will share my version on GitHub