HKUDS/Vibe-Trading · error · ValueError
unknown barrier type {barrier_type!r}; valid types: {BARRIER
Error message
unknown barrier type {barrier_type!r}; valid types: {BARRIER_TYPES} What it means
normalise_barrier_type folds the barrier_type string (case-insensitive, whitespace-trimmed) against a table of aliases mapping to the canonical types in BARRIER_TYPES ('down-and-out', 'down-and-in', 'up-and-out', 'up-and-in'). Anything not in the alias table raises this error listing the valid types, because guessing a barrier direction would misprice the option structurally.
Source
Thrown at agent/src/quantlib/options.py:116
"up and out": "up-and-out",
"uo": "up-and-out",
"uoc": "up-and-out",
"uop": "up-and-out",
"up-and-in": "up-and-in",
"up_and_in": "up-and-in",
"up and in": "up-and-in",
"ui": "up-and-in",
"uic": "up-and-in",
"uip": "up-and-in",
}
def normalise_barrier_type(barrier_type: str) -> str:
"""Fold a barrier-type string to one of :data:`BARRIER_TYPES`."""
cleaned = barrier_type.strip().lower()
if cleaned in _BARRIER_ALIASES:
return _BARRIER_ALIASES[cleaned]
raise ValueError(
f"unknown barrier type {barrier_type!r}; valid types: {BARRIER_TYPES}"
)
def normalise_option_type(option_type: str) -> str:
"""Fold an option-type string to ``"call"`` or ``"put"``.
Public because callers that *store* an option type must fold it with the
same rule the pricing functions use. Anything that keeps the raw string and
later compares it with ``== "call"`` will price a leg typed ``"Call"`` as a
call here and settle it as a put there.
WHY THIS ACCEPTS ALIASES BUT STILL REFUSES THE UNKNOWN
-----------------------------------------------------
There are two different failure modes and they need opposite treatment.
A config saying ``"C"``, ``"calls"`` or ``"认购"`` is *unambiguous* -- there
is exactly one thing it can mean, and refusing it breaks a working setup forView on GitHub (pinned to 80ffdda44c)
Solutions
- Use one of the canonical BARRIER_TYPES strings, e.g. 'down-and-out'.
- Print BARRIER_TYPES / inspect _BARRIER_ALIASES to see accepted spellings.
- Normalise user input centrally (whitelist + map) before it reaches the pricer.
Example fix
# before price = barrier_option_price(S, K, T, r, sigma, H, barrier_type='knock-out') # after price = barrier_option_price(S, K, T, r, sigma, H, barrier_type='down-and-out')
Defensive patterns
Strategy: type-guard
Validate before calling
from quantlib.options import BARRIER_TYPES
cleaned = barrier_type.strip().lower()
assert cleaned in BARRIER_TYPES, f'barrier_type must be one of {BARRIER_TYPES}' Type guard
def is_valid_barrier_type(s: str) -> bool:
return isinstance(s, str) and s.strip().lower() in {
'down-and-out', 'down-and-in', 'up-and-out', 'up-and-in'} Try / catch
try:
px = barrier_option_price(S, K, T, r, sigma, H, barrier_type)
except ValueError as e:
if 'unknown barrier type' in str(e):
raise ConfigError(f'barrier_type {barrier_type!r} not supported') from e
raise Prevention
- Use a Literal/Enum for barrier types in your own config layer.
- Whitelist-map external codes to canonical strings at ingestion.
- Keep a unit test enumerating BARRIER_TYPES.
When it happens
Trigger: Calling barrier_option_price(..., barrier_type='knock-out') or 'dao', 'Down and Out' with wrong separators, or a typo like 'down-and-in '; any string not present in _BARRIER_ALIASES after lowercasing/stripping.
Common situations: Porting code from a library with different names (QuantLib uses 'DownOut', PyVOL uses 'UO'); user-supplied config with free-text barrier names; abbreviations like 'DO'/'UI' that are not in the alias map.
Understand the failure class
Background: Invalid enum value errors: "Unknown type", "Invalid scope", "must be one of" — when a string is not on the library's allowed list — this error's family across 23 libraries.
Related errors
- unrecognised option_type {option_type!r}. Accepted (any case
- Spot, strike, and barrier must be strictly positive, got S={
- S and K must be > 0, got S={S}, K={K}
- Unhandled barrier type {b_type}
- delay requires n >= 1 (lookahead ban)
AI-assisted analysis of HKUDS/Vibe-Trading@80ffdda44c (2026-08-28).
Data as JSON: /api/errors/36a7d0f710db2459.
Report an issue: GitHub.