[MONGOCRYPT-49] libmongocrypt: revisit error vs. abort on misuse Created: 01/Mar/19  Updated: 28/Oct/23  Resolved: 03/Jun/19

Status: Closed
Project: Libmongocrypt
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major - P3
Reporter: Samantha Ritter (Inactive) Assignee: Samantha Ritter (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Epic Link: Build libmongocrypt library

 Description   

Decide how to fail when drivers call into the wrong state machine methods:

  • BSON_ASSERT and crash?
  • do nothing, and continue to report the same state until they call the correct state machine method?
  • transition to the ERROR state ?


 Comments   
Comment by Githook User [ 03/Jun/19 ]

Author:

{'name': 'samantharitter', 'email': 'samantha.ritter@10gen.com', 'username': 'samantharitter'}

Message: CDRIVER-2988 replace asserts with returned errors
Branch: master
https://github.com/10gen/libmongocrypt/commit/c6ad036738f5b67fafbd637b8e9bc5d536c0a6a1

Comment by Kevin Albertson [ 28/Mar/19 ]

From collected experiences PoC'ing libmongocrypt in the Node and Java drivers, I'm convinced we should error where possible instead of asserting. Even simple cases like accidentally passing NULL as an argument when you shouldn't. It just makes the process of integrating the library and debugging easier. And one of the primary goals of libmongocrypt is to make FLE easy to implement in drivers.

Also a couple noteworthy cases we should error (and not abort):

  • reinitializing a mongocrypt_ctx_t
  • omitting necessary calls to mongocrypt_ctx_mongo_done
  • bad option values in mongocrypt_init
Comment by Kevin Albertson [ 08/Mar/19 ]

If we decide to go with return an error instead of aborting in all cases, let's update errors in kms-message that abort too (e.g. kms_request_str_appendf). That may be a separate ticket.

Generated at Thu Feb 08 09:07:50 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.