<@U751GPTU7> Option 1 means `catch exception` -&gt...

# codingconventions

[Andreas Sinz]

@travis Option 1 means catch exception -> put it in a Result -> rethrow another/the same exception, so definitely Option 2

[travis]

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?

[travis]

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)?

[travis]

(just playing devils advocate, I'm leaning towards option 2, just wanted to get feedback to make sure I'm not overlooking something)

[Andreas Sinz]

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

[Andreas Sinz]

just make sure that a method just has one thing to do, that improves the reusability

[Andreas Sinz]

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)
}

[travis]

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?

[Andreas Sinz]

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

[Andreas Sinz]

that was just an example of an Api you are using that returns an error-code or the actual data

[travis]

Ohhh

[travis]

The data & responseCode actually comes back as separate parameters in a callback, so I have to "luxury" of deciding how to package it.

[Andreas Sinz]

I just wanted to highlight, that its not necessary that MyApi.readData calls MyApi.readDataAsResult or vice-versa

[travis]

I see.

[Andreas Sinz]

i think I get what you are talking about. you mean the data flows like that? Api -> core -> Extension methods?

[travis]

Yup

[travis]

Or that is where I was going with it thus far.

[Andreas Sinz]

right and if you'd get an error-code from Api you'd throw exception based on error-code -> catch excetpion -> return result?

[travis]

For option 2, yes.

[travis]

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

[Andreas Sinz]

is it necessary to distinguish between core and extension method?

[Andreas Sinz]

or lets say having readData and readDataAsResult inside core?

[travis]

Both methods could certainly be inside the core Api class (if that's what you mean?).

[travis]

I was having some of the Api split into extension to make it an optional module that people could import.

[travis]

To keep the "core" Api simple and minimalistic but optionally add convenience extensions.

[travis]

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)

[Andreas Sinz]

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

[Andreas Sinz]

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)

[travis]

Awesome, very insightful. Thanks!