Hi folks, i have created a sealed class just for t...

# codereview

[George]

Hi folks, i have created a sealed class just for the sake of not returning a type of nullable failure, in other words if return type is null then it is the success scenario, wdyt?
Here is the sealed class:

// a union between unit and failure type, to avoid return type of nullable `Reject`
private sealed class ContinueOrReject
private object Continue : ContinueOrReject()
private class Reject(val rejectionDetails: RejectionDetails) : ContinueOrReject()

Any review or pov are welcomed and and thanks in advance for any answer !

[Joffrey]

I would have no objections to that. It depends a bit on the meaning of the function that returns this class. If the function is meant to retrieve or collect errors, then I don't have a problem with a nullable error type. If the function performs an operation and incidentally reports errors, then I like the sealed class approach

[George]

Im not sure i get what are differences between your two examples.

I use it on two validator functions: they validate input data and report only errors or return Continue to mark that the validation finished successfully.

my goal: avoid returning a Reject? which means if is null then the validation finished successfully.

[George]

If the function is meant to retrieve or collect errors an example of this would be to try collect some data from somewhere which is known that are type of errors? Something like this?

[Joffrey]

Yes, I meant something like getError(): SomeError? wouldn't feel wrong to me. But saveFoo(foo: Foo): SomeError? would seem strange, and I would prefer saveFoo(foo: Foo): Result

[Joffrey]

In the case of validation it's a bit of a mix between the 2, so it's not as clear cut. I think I prefer the result sealed class in your case, though

[George]

Ok cool, thanks !