Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong stack trace index after using Swift wrapper #86

Closed
PhilipDukhov opened this issue Oct 22, 2021 · 1 comment
Closed

Wrong stack trace index after using Swift wrapper #86

PhilipDukhov opened this issue Oct 22, 2021 · 1 comment

Comments

@PhilipDukhov
Copy link
Contributor

I would like to use Napier in iOS part as well. This is not very convenient because Kotlin Native has some limitations:

  1. The converted code cannot have default parameters, so I had to specify throwable and tag in every call.
  2. The converted code cannot be used as a static function, and shared/Companion() must be specified manually.
  3. Because of the () -> String methods, the argument name tag cannot be used in both cases, and the String variant has the name tag_.

So my log code can look like this:

Napier.shared.d(message: "", throwable: nil, tag_: nil)

As far as I know, you can't do anything about these problems in kotlin part. That's why I wrote such a wrapper in Swift:

extension Napier {
    static func d(tag: String? = nil, _ items: Any..., separator: String = " ") {
        shared.d(message: items.joined(separator: separator), throwable: nil, tag_: tag)
    }
}

Everything works as expected, with one exception: because you use a constant stack trace index, the function name calculation is no longer correct.

I thought about adding another optional parameter to all calls that would indicate the shift in wrappers like mine, something like this:

fun d(message: String, throwable: Throwable? = null, tag: String? = null, stackTraceIndexShift: Int = 0) {
    // ...
}
extension Napier {
    static func d(tag: String? = nil, _ items: Any..., separator: String = " ") {
        shared.d(message: items.joined(separator: separator), throwable: nil, tag_: tag, stackTraceIndexShift: 1)
    }
}

But maybe you can come up with a more elegant solution

@PhilipDukhov
Copy link
Contributor Author

I found out that I can use log instead of a specific version, which will decrease the stack trace count to expected, but this still doesn't work as expected because iOS stack trace format is different from the kotlin one:

6   Napier 0x0000000100869644 kfun:io.github.aakira.napier.Napier#d(kotlin.String;kotlin.Throwable?;kotlin.String?){} + 280
7   Napier 0x0000000100913d28 objc2kotlin.259 + 252
8   Napier 0x00000001007f0e6c $s6Napier14ViewControllerC9configure33_527BB3C17EFDCFA47CE221EFAC2390B7LLyyF + 752

I'll try to parse it correctly and come back with the pull request

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant