Current Behavior
Currently, if code wraps createClient in a try/catch block, and the createClient call stumbles into at least some subclass of errors (e.g., it couldn't find the 1P desktop app), it emits an error on its own rather than just throwing the error so that the application can handle it in the catch block.
For example, if my app has the following, and a user runs the app without having the 1Password desktop client installed:
try {
onePasswordClient = await createClient({
auth: new DesktopAuth(ONE_PASSWORD_ACCOUNT),
integrationName: pkg.name,
integrationVersion: pkg.version,
});
} catch (err) {
console.log('Unable to connect to 1Password, so falling back to prompting for secrets prior to provisioning. If you have 1Password installed, ensure your Developer preference "Integrate with 1Password SDKs" is enabled.');
// (etc...)
}
then the 1Password SDK itself emits a big ugly error all on its own before displaying that console.log call occurs:
A critical error occurred while loading the native addon: Error: 1Password desktop application not found at find1passwordLibPath(C:\code\vault-config\node_modules\@1password\sdk\dist\shared_lib_core.js:90:11)
at new SharedLibCore (C:\code\vault-config\node_modules\@1password\sdk\dist\shared_lib_core.js:99:29)
at C:\code\vault-config\node_modules\@1password\sdk\dist\client_builder.js:27:23
at Generator.next (‹anonymous › y
at C:\code\vault-config\node_modules\@1password\sdk\dist\client_builder.js:8:71
at new Promise (‹anonymous>)
at createClientwithCore (C:\code\vault-config\node_modules \@1password\sdk\dist\client_builder.js:24:48)
at C: \code\vault-config\node_modules\@1password\sdk\dist\sdk.js:44:135
at Generator. next (‹anonymous>)
This error is emitted here, as a console.error from the SDK itself.
Desired Behavior
It would be great if the SDK just threw that error, and let an application decide how to handle it, rather than forcing it to be emitted to the console no matter what.
Benefits & Value
Application developers can control what their users see or don't see, and not have the SDK make those decisions. For example, in the above example, I would be able to emit a simple, descriptive message (even pushing the user to a link that explains how they can resolve the issue by installing the app and enabling SDK access) and then fall back to asking for secrets via prompts. Instead, though, users see the SDK's own error message and the stack trace.
Additional information
No response
Current Behavior
Currently, if code wraps
createClientin atry/catchblock, and thecreateClientcall stumbles into at least some subclass of errors (e.g., it couldn't find the 1P desktop app), it emits an error on its own rather than just throwing the error so that the application can handle it in thecatchblock.For example, if my app has the following, and a user runs the app without having the 1Password desktop client installed:
then the 1Password SDK itself emits a big ugly error all on its own before displaying that
console.logcall occurs:This error is emitted here, as a
console.errorfrom the SDK itself.Desired Behavior
It would be great if the SDK just threw that error, and let an application decide how to handle it, rather than forcing it to be emitted to the console no matter what.
Benefits & Value
Application developers can control what their users see or don't see, and not have the SDK make those decisions. For example, in the above example, I would be able to emit a simple, descriptive message (even pushing the user to a link that explains how they can resolve the issue by installing the app and enabling SDK access) and then fall back to asking for secrets via prompts. Instead, though, users see the SDK's own error message and the stack trace.
Additional information
No response