capacitor-community / capacitor-community/bluetooth-le

Throw error codes instead of message strings in the exception

Open
#697 2 comments 0 reactions 0 assignees View on GitHub
enhancement
Dominant language
TypeScript
Stars
361
Forks
121
Avg merge
10d 45m
Merged PRs (30d)
2

Description

**Is your feature request related to a problem? Please describe.**
So far the current exceptions thrown have string based messages which is sometimes event differenet between the platforms, whiuch would make it hard to interpret the resulting issue. such as in https://github.com/capacitor-community/bluetooth-le/blob/83e2b1b45c65ad0835210826814830ae9d575ea8/ios/Plugin/DeviceManager.swift#L50 for iOS and https://github.com/capacitor-community/bluetooth-le/blob/83e2b1b45c65ad0835210826814830ae9d575ea8/android/src/main/java/com/capacitorjs/community/plugins/bluetoothle/BluetoothLe.kt#L139 for Android which basically are permession denials however they are different strings which means the parser on the app side would need to take care about bopth scenarios and this owuld be way easier if it was error codes and would prevent the issue of someone changing the string inside the library causing the parser on the appp end to fail

**Describe the solution you'd like**
Have error codes instead of string based exceptions so that the user can interpret the values of the error codes way easier than whole strings.

Contributor guide

Open the contributing guide

Research direction

Start with the referenced iOS file ios/Plugin/DeviceManager.swift around line 50 and Android file android/src/main/java/com/capacitorjs/community/plugins/bluetoothle/BluetoothLe.kt around line 139. Compare how permission-denial exceptions are produced on each platform and trace how the TypeScript-facing plugin exposes them. Done means the platforms provide stable error codes so app parsers no longer depend on platform-specific message strings.

Written by the indexing model from the issue text.

Assessment

Tech stack
kotlin, swift, typescript
Domain
api, mobile-dev
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.