https://kotlinlang.org logo
Title
a

Andreas Sinz

04/30/2018, 6:26 PM
@travis Option 1 means
catch exception
->
put it in a Result
->
rethrow another/the same exception
, so definitely Option 2
t

travis

04/30/2018, 6:29 PM
What if the underlying library that the
Api
will be using captures exceptions itself to return specific result codes? They are already doing
catch exception
return as result code
? Does that change how I should approach it?
i.e. doesn't option 1 allow the user of
Api
to never have to deal with exceptions (as the only time exceptions are thrown are when they use the extension functions)?
(just playing devils advocate, I'm leaning towards option 2, just wanted to get feedback to make sure I'm not overlooking something)
a

Andreas Sinz

04/30/2018, 6:36 PM
the question is, do these methods have to use the "other version" of itself. If the
Api
already returns an error code, you could just create two methods:
getData
returns the data or throws an exception and
getDataAsResult
that calls the same
Api
but returns a
Result
just make sure that a method just has one thing to do, that improves the reusability
👍 1
contrived example:
//Returns an Int as error-Code or
// String as Data
fun Api.readData(): Any

@throws MyException
fun MyApi.readData(): String {
    val data = Api.readData()
    
    if(data is Int)
        throw MyException(data)

    return data as String
}

fun MyApi.readDataAsResult(): Result<String> {
    val data = Api.readData()

    return if(data is Int)
        Result.Error(data)
    else
        Result.Success(data as String)
}
t

travis

04/30/2018, 6:45 PM
Hmm, interesting approach of splitting the responsibility between the extension functions. Although wouldn't the
Any
return from the core function be more error prone?
a

Andreas Sinz

04/30/2018, 6:45 PM
and if you need to do something with
data
first, just create another function:
fun MyApi.parseData(): Data {
    val data = Api.readData()

    //Do Work with Data

    return newData
}
and use this function inside
MyApi.readData
and
MyApi.readDataAsResult
instead of the original function
that was just an example of an
Api
you are using that returns an error-code or the actual data
t

travis

04/30/2018, 6:46 PM
Ohhh
The
data
&
responseCode
actually comes back as separate parameters in a callback, so I have to "luxury" of deciding how to package it.
a

Andreas Sinz

04/30/2018, 6:47 PM
I just wanted to highlight, that its not necessary that
MyApi.readData
calls
MyApi.readDataAsResult
or vice-versa
t

travis

04/30/2018, 6:47 PM
I see.
a

Andreas Sinz

04/30/2018, 6:50 PM
i think I get what you are talking about. you mean the data flows like that?
Api
->
core
->
Extension methods
?
t

travis

04/30/2018, 6:51 PM
Yup
Or that is where I was going with it thus far.
a

Andreas Sinz

04/30/2018, 6:52 PM
right and if you'd get an error-code from
Api
you'd
throw exception based on error-code
->
catch excetpion
->
return result
?
t

travis

04/30/2018, 6:52 PM
For option 2, yes.
Whereas with option 1 I'd package the
data
& result code in
Result
and only throw via extension function:
Result based on error-code
->
return result
-> (optional use of extension)
throw exception
a

Andreas Sinz

04/30/2018, 6:55 PM
is it necessary to distinguish between
core
and
extension method
?
or lets say having
readData
and
readDataAsResult
inside core?
t

travis

04/30/2018, 6:56 PM
Both methods could certainly be inside the core
Api
class (if that's what you mean?).
I was having some of the Api split into extension to make it an optional module that people could import.
To keep the "core" Api simple and minimalistic but optionally add convenience extensions.
So I guess the question is: is an API easier to use if it throws or returns a
Result
? (as it's "default", i.e. pre-extension function impl)
a

Andreas Sinz

04/30/2018, 7:03 PM
if the
Api
returns more often an error-code than it throws, I'd use Option 1, otherwise Option 2 just to have as little overhead as possible
👌 1
you won't be able to remove all overhead if you split the code into
core
and
extensions
and the
Api
doesn't have consistent return types (sometimes throws, sometimes returns error codes)
t

travis

04/30/2018, 7:04 PM
Awesome, very insightful. Thanks!
👍 1