<https://github.com/JetBrains/kotlin/blob/master/l...

# stdlib

[rrader]

https://github.com/JetBrains/kotlin/blob/master/libraries/stdlib/jvm/runtime/kotlin/jvm/internal/Intrinsics.java#L138
Can you please replace IllegalArgumentException with another exception? that will store property name and will be possible to get that property name and not to parse the error string

[karelpeeters]

Why do you need to catch it?

[rrader]

We build a Json library, and need to create a instance of class, and need to show what field failed

[rrader]

to not break the code, the new exception class can be a child of IllegalArgumentException

[karelpeeters]

Can't you look at the type of the arguments?

[rrader]

These check are already done by Kotlin, so we want to reuse them

[karelpeeters]

Hmm, `IllegalArgumentException`s aren't meant to be caught, even in Java. They should always be indicative of a programmer error.

[gildor]

I agree with Karel, reuse asserts for this doesn't seem correct for me.
Parsing shouldn't create instance or class. If you use reflections you can check nullability of constructor argument

[rrader]

And how will be if Kotlin team will allow to disable this checks? We should rewrite our code? Why not just reuse this checks?

[rrader]

And why to limit library writers? Kotlin team just need to provide good tools, after is our decision to use or not

[gildor]

And how will be if Kotlin team will allow to disable this checks

Yes, you right, this check already can be disabled using compiler flag

Why not just reuse this checks?

Because it not intended to be reused

And why to limit library writers

I don’t see any limitation.s You already has tools to solve this problem: kotlin-reflect and kotlin-metadata

[rrader]

Well, as you said we also should check the compiler flags

[rrader]

And also should track if other ways will not apear to disable that checks

[rrader]

Because it not intended to be reused

why to not make to be reused, do you know some limitations?

[gildor]

Well, as you said we also should check the compiler flags

No! You shouldn’t if you just check it yourself

[rrader]

Hm, how can I check if I not check the flags?

[gildor]

As I said before, you shouldn’t rely on runtime asserts to validate serialized data. Instead, you should rely on semantics of original code. To do that you check constructor arguments nullability using kotlin-reflect (for runtime) or metadata information (for compile-time)
So yes, you should check nullability yourself, do not expect that runtime will throw exception

[rrader]

Ok, what should I check with kotlin-reflect?

[gildor]

This is what all Kotlin specific serialisers do like kotlinx.serialization, moshi-kotlin, #klaxon etc

[rrader]

ok, but what should I check with kotlin-reflect?

[gildor]

that argument is nullable or not

[gildor]

so if it’s nullable it’s fine to pass null there, if not, but deserialized value is null you should throw own error or handle it in some other way

[rrader]

this is not correct with flags

[rrader]

the flags will not remove nullability from parameters, they just remove intrisics

[gildor]

I don’t understand what you mean

[gildor]

yes, of course

[gildor]

but why would you check for intrinsics behaviour?

[gildor]

need to create a instance of class, and need to show what field failed

[gildor]

this is your original task

[rrader]

because validation is done by other tool not by kotlin

[gildor]

to solve it, you validate data before actual instance creation

[rrader]

so, double work

[gildor]

Maybe you could give more context, because it’s now not clear for me what you want to achieve.
What is your case, when instance creation may be failed because of nullability?

[gildor]

If validation is done already, why would you handle intrinsic errors which signal only about incorrect state

[rrader]

I want what nullability validation to be done by other tool, not kotlin, because kotlin fail on first parameter, and I need to collect all possible errors, I need this when receive json from client

[rrader]

the validation by tool is done only after object creation

[gildor]

In this case you don’t validate data, you validate that mapping of data to kotlin code is valid, so not sure how 3rd party tool can do that

[rrader]

this is why I need to disable kotlin checks

[gildor]

I want what nullability validation to be done by other tool, not kotlin, because kotlin fail on first para

how 3rd party tool can check nullability of Kotlin types?

[rrader]

kotlin adds @NotNull to that parameters, so after object creation the tool can check properties that has this annotation if they are null

[gildor]

What kind tool it is?

[rrader]

Spring + @Valid

[rrader]

so if a parameter in Spring has @Valid it will validate the object before passing to method

[gildor]

okay, probably would be better to start from this, that you use Sprint and JSR-303

[rrader]

well, maybe

[gildor]

Did you see this?
https://stackoverflow.com/questions/35847763/kotlin-data-class-bean-validation-jsr-303

[rrader]

not this, but I already use the annotation, the only issue is with null

[rrader]

because kotlin fail on first null

[gildor]

I don’t think that you can solve it now, only marking properties as nullable, same way as it work in Java

[rrader]

I can't do all other checks, because I can not create the object

[gildor]

Another option tot somehow integrate Kotlin support to spring validation

[gildor]

I think only working solution is mark everything as nullable

[rrader]

no

[rrader]

I already made it

[gildor]

and what did you do?

[rrader]

just need to thor anothr exception

[rrader]

and thats it

[rrader]

I have all my requests/json in separate module, disabled intrisics only for this module, and validation is done by Spring, but in kotlin jackson module that is using by Spring they also check paramers before object creation, so if in that module check will be reused everything will work

[rrader]

so to fix this in jackson kotlin module I just need to throw a new exception

[gildor]

Looks like really dirty hack rather than solution

[gildor]

But I see your pain. JSR-303 is too java-specific

[gildor]

we probably need some proper solution for this on Kotlin

[rrader]

maybe it's a hack, but everything works as expected

[gildor]

like compiler plugin that validates before object creation or some Spring integration that doesn’t try to construct invalid object, but checks data before object creation

[rrader]

I have an idea now, maybe to add as metadata to each parametr if intrisics was generated for it, so in library we can check just that info

[rrader]

no matter what disabled the intrisics, we just check that info

[rrader]

the issue with plugin will be that validation can be custom, and it only works after object creation, so it will not be a working solution

[gildor]

I still think that solution with intrinsic disabling is bad. Because you actually need intrinsics, not valid class shouldn’t be created, at least in theory

[gildor]

on can be custom, and it only works after object creation,

why? Because validation checks other fields?

[rrader]

also, it can has some logic, or even read from database

[rrader]

this is how work Spring + JSR-303

[rrader]

it create object and after that do validation

[rrader]

another point is, that object is created by jackson library, and in jackson library do not want to add anything about validation

[rrader]

I will be happy to not disable intrisics, but I need a working solution 🙂

[gildor]

Yes, I understand

[gildor]

Annotation to disable intrinsics also may be implemented as compiler plugin, but it’s long term solution

[rrader]

do you mean https://youtrack.jetbrains.com/issue/KT-23335 ?

[sandwwraith]

This would be eventually replaced with `KNPE`: https://youtrack.jetbrains.com/issue/KT-22275

[rrader]

Oh, thanks
also in #klaxon also recomand to do validation after object creation https://kotlinlang.slack.com/conversation/C90AVCDQU/p1545835141006600

[sandwwraith]

Well, it makes some sense: validation happens after creation, and if object can not be created, there's nothing to validate

[gildor]

I don't see that Klaxon recommended to do validation after object creation, just that Klaxon doesn't provide any facilities for custom validation.
Also, Klaxon checks for nullability of arguments and will not allow create an object if nullability doesn't match to argument even without intrinsic assert

I believe that 2 steps of validation is just fine.
Checking for null is not something different from checking that property type is compatible, that you do not try to deserialize array to int or other basic type-system check.
Validator of any (de)serializer does basic checks in any case and even sometimes provide some facilities for fallback, like use default value (predefined or default for particular type, like 0 or empty string)
The only reason why nullability is part of jsr-303 is that Java doesn't have nullability on type system (same way as Kotlin or Java don't have number range check)

The same way Jackson in Spring will throw exception before class instance creation in case of incompatible types.

[gildor]

I understand that it probably not what Spring provides out of the box, but I think it's right approach.
Also really curious, do you use Jackson-module-kotlin? Because I thought that it should provide nullability check before object creation and do not create invalid objects

[rrader]

Yes I use that module, and yes it checks before creation

[rrader]

And I want to modify that behavior

[rrader]

Well, user of application will not be happy to see 2 times validation errors

[rrader]

he expect to see at once all the validation errors

[gildor]

But user will see only 1 validation error, depending on level of error (deserializer or validator). Also it's possible to avoid nullability for most cases, especially with power of Jackson: use default values for primitives (I believe this is already default behavior), empty string and empty collections and default values for your own classes
Of course it depends on use case, but probably better just solve nullability problem on serializer level rather than on high level validator

[rrader]

But user will see only 1 validation error

this is the problem, user want to see all errors at once

use default values for primitives

hm, usually you do not have default at all