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

refactor: centralize Android NFC method exception handling #169

Merged
merged 1 commit into from
Jun 1, 2024

Conversation

knthm
Copy link
Contributor

@knthm knthm commented May 29, 2024

Reduces code duplication and improves readability.

Fixes #168

@Harry-Chen
Copy link
Contributor

Thanks! I am actually thinking about some more elegant ways to handle all possible exceptions. Something like:

fun handleException(ex: Exception, result: Result?, desc: String) {
    Log.e(TAG, "$desc error", ex)
    val excMessage = ex.localizedMessage
    when (ex) {
        is IOException -> result?.error("500", "Communication error", excMessage )
        is SecurityException -> result?.error("503", "Tag already removed", excMessage)
        // some more types
        else -> result?.error("510", "Unhandled error", excMessage) // I choose this code just randomly.
    }
}

Then it could be called from all catch blocks. What's your opinion on this?

@knthm
Copy link
Contributor Author

knthm commented May 29, 2024

With the current amount of catch blocks per operation I was thinking along the same lines, but thought it safer at first to maintain the same pattern.

I suppose refactoring the exception handling wouldn't take too much time and would definitely make things a lot cleaner.

My main concern is I can't physically test the other tag types to ensure the behavior triggering the exception doesn't differ slightly.

@Harry-Chen
Copy link
Contributor

My main concern is I can't physically test the other tag types to ensure the behavior triggering the exception doesn't differ slightly.

AFAIK Android NFC APIs mainly throw:

  • IOException and SecurityException in every IO-related API
  • IllegalArgumentException in transceive
  • FormatException in NDEF-related APIs

There are additional InvocationTargetException and NoSuchMethodException because reflection is used to simplify transceive.

Seems it's safe to refactor, since no two different APIs throws the same exceptions except IOException and SecurityException.

@knthm knthm changed the title fix: MIFARE: catch SecurityExceptions refactor: centralize Android NFC method exception handling May 31, 2024
@knthm knthm force-pushed the fix-mifare-security-exceptions branch 2 times, most recently from f115a3e to 27fe9ba Compare May 31, 2024 15:12
@knthm
Copy link
Contributor Author

knthm commented May 31, 2024

Good points, I went ahead and offloaded it into more or less the copy-pasted version of your suggestion :)

@Harry-Chen
Copy link
Contributor

Yeah! This looks much better now. I just found that it could be merged into runOnNfcThread, like:

private fun runOnNfcThread(result: Result, desc: String, fn: () -> Unit) {
    val wrappedFn = Runnable {
        try {
            fn()
        } catch (ex: Exception) {
            handleException(ex, result, desc)
        }
    }
    if (!nfcHandler.post(fn)) {
        result.error("500", "Failed to post job to NFC Handler thread.", null)
    }
}

Then:

By the way, there is an extra space at:

is IOException -> result?.error("500", "Communication error", excMessage )

Will you please make the changes, and I'm really happy to merge.

@knthm knthm force-pushed the fix-mifare-security-exceptions branch from 27fe9ba to a59477d Compare May 31, 2024 16:12
@knthm
Copy link
Contributor Author

knthm commented May 31, 2024

I just found that it could be merged into runOnNfcThread

Oh! That's a lot better, agreed.

I ended up moving handleException into runOnNfcThread, since their usage is mutually inclusive, IMHO.

Resolved the other two mentions as well.

@knthm knthm force-pushed the fix-mifare-security-exceptions branch from a59477d to 18e4684 Compare May 31, 2024 22:42
@Harry-Chen Harry-Chen merged commit 2773020 into nfcim:master Jun 1, 2024
2 checks passed
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

Successfully merging this pull request may close these issues.

bug: MIFARE: unhandled security exceptions
2 participants