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 for

View on GitHub (pinned to 80ffdda44c)

Solutions

  1. Use one of the canonical BARRIER_TYPES strings, e.g. 'down-and-out'.
  2. Print BARRIER_TYPES / inspect _BARRIER_ALIASES to see accepted spellings.
  3. 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

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


AI-assisted analysis of HKUDS/Vibe-Trading@80ffdda44c (2026-08-28). Data as JSON: /api/errors/36a7d0f710db2459. Report an issue: GitHub.