You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
# Proposal: Standardize Configuration Type Conversion Behavior
2
+
3
+
## Summary
4
+
5
+
We propose standardizing configuration type conversion behavior across all data types in the next major release, specifically changing how invalid boolean values are handled to match the behavior of other numeric types.
6
+
7
+
## Current Problem
8
+
9
+
### Inconsistent Behavior Between Data Types
10
+
11
+
Currently, our configuration system exhibits inconsistent behavior when handling invalid values:
12
+
13
+
**Numeric Types (Integer, Float, Double, Long):**
14
+
```java
15
+
// Environment: DD_SOME_INT=invalid_number
16
+
int value = configProvider.getInteger("some.int", 42);
17
+
// Result: 42 (default value) ✅
18
+
```
19
+
20
+
**Boolean Type:**
21
+
```java
22
+
// Environment: DD_SOME_BOOL=invalid_boolean
23
+
boolean value = configProvider.getBoolean("some.bool", true);
24
+
// Result: false (hardcoded fallback) ❌
25
+
```
26
+
27
+
### Why This Is Problematic
28
+
29
+
1.**Unexpected Behavior**: Users expect invalid values to fall back to their explicitly provided defaults
30
+
2.**Silent Failures**: Invalid boolean configurations silently become `false`, making debugging difficult
31
+
3.**API Inconsistency**: Different data types behave differently for the same logical error condition
32
+
4.**Code Complexity**: Requires custom exception handling and special-case logic
33
+
34
+
## Current Implementation (Temporary Workaround)
35
+
36
+
To maintain backward compatibility while fixing our test suite, we implemented a temporary solution:
0 commit comments