What's the accepted practice for not found situations in repos and apis? Say I have

userRepo.getUser(userId)

and it wasn't found, should it return null, throw a domain exception (NoUserFoundException) or have a sealed class with a null object? (I'm using coroutines, not Rx...)

Not sure what "best practice" is but we have both getUser and findUser. getUser throws if not found and findUser returns User?. I find that it is often the caller that has be best idea of what to do

If the caller is Kotlin, your signature should be

fun getUser(id: YourIdType): User?

and you return

null

when User can't be found; if the caller can be Java, I'd go with

Optional<User>

return type. Throw is bad practice here, because you're forcing try/catch semantics when your caller might be okay with not finding a user.

The purpose is to rid every requireUser callsite of a ?: error("Missing user with id $id"). Much like kotlins Map.getValue. But each to his own 🙂

Yup, opinion only, it also really depends on usage context. If

?: error("")

is something you'll find yourself writing more often than (

?.let {}

), then by all means

get/find

(where

get

throws and

find

returns

null

) is indeed a better approach. I'm probably just a bit biased due to the latest project I worked on, which didn't have many

?: error("")

situations, if something wasn't found it didn't mean an error has happened. 🙂

Thanks alot for the insights @Czar and @spand! When would you use null objects/sealed classes? But then, maybe I'm asking from a context of translating code from Rx, I guess in coroutines it would be simpler, unless using a channel like in Rx where you have to keep the channel open and constantly representing a current valid state... here this might not apply.

I wouldn't because I'm not very familiar with the concept, I think it comes from more functional approach, with which I'm not nearly fluent.

@dave08 I usually follow this rule: https://stackoverflow.com/a/19061110/4706743

@Andreas Sinz Very interesting addition, thanks! We all think about this more or less, but its easy to overlook when under pressure...

If your function can either throw or return

null

, I've seen

findUser()/findUserNoThrow()

or

findUser()/findUserOrNull()

. This is more useful in libraries where you want to give your users options.

@cedric You're suggesting that the throw version should be the default? Our use case is not in a library, but rather in the model/networking layer of our internal projects.

To be honest, I don't know. I don't think there is a single answer, it depends a lot on the scenario.

As a rule of thumb I would not use

?

or

Option

to denote User not found if you want to remain exception free. Does it have the same semantics to not actually finding the user to say the network is down? I'd model the exceptional known cases in an ADT and return a disjunction of a known error case or the actual value:

sealed class ApiError
object NetworkFailure: ApiError()
data class UserNotFound(val id: String): ApiError()

fun findUser(): Deferred<Either<ApiError, User>> = TODO()

You loose valuable types and semantics when modeling known cases with just

?

or

Option

and you may need those down the road to display appropriate error messages or branch out biz logic into the unhappy path. If you are interested in an FP approach to error handling more info here: http://arrow-kt.io/docs/patterns/error_handling/

imo the function should never throw if the input is legal, i.e. the user not being found is an expected result of the function. That possibility should be encoded in the function signature either through nullable types or something like

Maybe

. I prefer nullable types for non-rx functions because they're nicer to use.

?.

is like

Maybe.flatMap

anyway

@tschuchort I wouldn’t go that far. Just because the input is legal doesn’t mean the function can handle it (i.e. be total on that input)

@raulraja That's part of what I was doing in Rx... but I think that it might be adding an extra layer of complexity... I think that you are right in certain cases though. I'll note the link anyways, we could always learn something 😄 @cedric #1 is understood, but what's equational reasoning?

@dave08 The ability to equate your type signatures with logical proofs, which can give you a certain amount of confidence about the soundness of your code. A “certain” amount. There’s still runtime code that’s not accounted by this static analysis.

To add to @cedric's comment, the way I see it is that Equational reasoning is a property of programs declared in terms of total and pure functions. Pure: They produce the same output for the same input and do not change their outter state or perform uncontrolled effects. Total: As implemented these functions contemplate all cases in which their input may be found itselft into, for example when you use

when

over a sealed class hierarchy). An example of pure and total functions are:

fun add(a: Int, b: Int): Int = a + b

And example of an impure one:

var x: Int = 0
fun addToX(a: Int): Int = x = x + a

Why should throwing be any different from a

return

in the middle of

fun

logic? Also, even exceptions can be unit tested...? @raulraja You still needed to use an external

var x

to make it impure, the exception didn't do it, did it?

the exception did it too

If you want a quick peek at what it means: When you read code and you see something like

F => T

, you will typically think “It’s a function that takes a parameter of type

F

and returns a parameter of type

T

. Here is the cool part: now read this from a mathematical eye and you’ll read “F implies T”. There is actually a mathematical equivalence between these two interpretations: they are strictly equivalent according to a theorem that was proven decades ago.

@dave08 yeah you can test anything

Retreiving data from network or a db is intrinsically not 'pure' too...?

right unless encapsulated in a data type that can suspend that computation

@dave08 To answer this question, ask yourself: “Is it possible to call this function with the same parameters twice and receive different results?“. If the answer is yes -> impure

But purity is a necessary but not sufficient condition: your function can be pure but have side effects, something that’s undesirable if you want to stay within the realm of equational reasoning

That is

pure

because

printLater

performs no effects, it just returns a function that does.

@cedric So, back to the original issue, using sealed classes andd Either to represent the return value of getUser, would make my function closer to being pure?

Usually, the types you choose to return have no impact on whether your function is pure or not. What matters is what’s inside that function (the runtime aspect).

I think moving the effect of absence or error handling to the type guarantees that callers to your function deal with that case because it is returned as value. If you throw you have no guarantees your users will handle the exception.

Except if you throw a checked exception…

Ooh, now I think I got it! Side effects shouldn't be brought in to a pure function, but a pure function might have side effects... that's not desirable. @raulraja So the goal here is not for pure

fun

, but rather for total

fun

?

but Kotlin code would not have to handle the checked

@Throws

exceptions right?

@raulraja Yeah Kotlin will happily ignore it

A pure function is not pure if it has side effects not captured by it's types. Try to write one. Pure functions produce no side effects when invoked, that means no change to the world state outside the function.

One important aspect of purity is that you can see by the types what the function does. If your function throws, you can not see that in the function signature, but if you use Either then it's clear to everyone that the function might fail and what kids of errors it might return. In fact you will be forced to handle all possible results, which will drastically reduce the amount of bugs in your code

@tschuchort On the JVM, the throws is part of the signature

@cedric That was my original thought (actually I remember vaguely seeing you mention it in this slack...). @raulraja i guess it all depends on how important equational reasoning is in each case like @cedric put so well, and you both gave me more valuable insight on this, these concepts are nice additions to a programmers toolbox 😄 One last little thing, why doesn't Kotlin enforce @Throws?

Because checked exceptions don’t work well with composition: `foo().bar().baz()`: if any of these has a checked exception, it gets ugly fast

That's not particular to Kotlin... also the exceptions will still through and the developer won't know what hit him if it's not enforced...

and back to my point, exceptions are generally not desirable unless you are in an environment that requires them

The cost factor is incorrect and not worth bringing up in my opinion

I'd love to understand why is incorrect, you mean this is not accurate http://normanmaurer.me/blog/2013/11/09/The-hidden-performance-costs-of-instantiating-Throwables/ ?happy to continue in DM. I'd like to understand if they that is wrong, other post I've read seem to agree.

Instantiating is cheap. Throwing is more expensive but it should be rare. Either way, you’ll probably never find anything related to exceptions in the top 10 lines of a profiler dump.

You may not find those as often as IO in DBs or network but the performance of instantiating the Throwable is directly affected by the size of the current stack and calls into native code so it's platform dependent and people abuse them to signal control in performance sensitive code frequently without understanding this because it's an implementation detail hidden in the super constructor.