pydantic/monty · error · Error
Invalid display format: '${format}'. Expected 'type-msg' or
Error message
Invalid display format: '${format}'. Expected 'type-msg' or 'msg' What it means
Thrown by the `display()` method of a Monty error wrapper when its `format` argument is neither the string `'type-msg'` nor `'msg'` (nor omitted, which defaults to `'msg'`). It is a plain developer-facing argument-validation error: the caller passed an unsupported format literal to the formatter, so no exception data is involved. Fix the call site to pass one of the two allowed format strings.
Source
Thrown at crates/monty-js/ts/errors.ts:62
}
/** Information about the inner Python exception. */
get exception(): ExceptionInfo {
return { typeName: this.typeName, message: this.innerMessage }
}
/**
* Formats the exception: `'type-msg'` for `ExceptionType: message`,
* `'msg'` (default) for just the message.
*/
display(format: 'type-msg' | 'msg' = 'msg'): string {
switch (format) {
case 'msg':
return this.innerMessage
case 'type-msg':
return this.innerMessage ? `${this.typeName}: ${this.innerMessage}` : this.typeName
default:
throw new Error(`Invalid display format: '${format}'. Expected 'type-msg' or 'msg'`)
}
}
}
/**
* Raised when the fed code cannot be parsed. The inner exception is always a
* `SyntaxError`.
*/
export class MontySyntaxError extends MontyError {
private readonly tracebackText: string
constructor(message: string, tracebackText = '') {
super('SyntaxError', message)
this.name = 'MontySyntaxError'
this.tracebackText = tracebackText
}
/**View on GitHub (pinned to adc986b362)
Solutions
- Call display('msg') for the bare message or display('type-msg') for 'Type: message'
- Validate/whitelist the format value before calling display
- Fall back: const text = fmt === 'msg' || fmt === 'type-msg' ? err.display(fmt) : err.display('type-msg')
Example fix
// before
const text = err.display('short');
// after
const text = err.display('type-msg'); Defensive patterns
Strategy: type-guard
Validate before calling
const DISPLAY_FORMATS = ['msg', 'type-msg']; if (!DISPLAY_FORMATS.includes(fmt)) fmt = 'type-msg';
Type guard
function isDisplayFormat(v) {
return v === 'msg' || v === 'type-msg';
} Try / catch
try {
text = err.display(fmt);
} catch (e) {
if (e instanceof Error && e.message.includes('Invalid display format')) {
text = err.display('type-msg');
} else throw e;
} Prevention
- Only use the literal strings 'msg' and 'type-msg'
- Whitelist user-configurable format options before passing them to display()
- Centralize error formatting in one helper that hardcodes the valid formats
When it happens
Trigger: Calling error.display('short'), display('full'), or a dynamically computed format string that is not exactly one of the two supported literals.
Common situations: Guessing format names from other logging libraries; user-configurable display options flowing through unchecked; typos like 'type_msg'.
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
- invalid mode: '${char}'
- ClassInstance expects an object instance
- notCallableMessage(method)
- ClassInstance expects an instance of a class, not a null-pro
- classType does not match the instance's class
AI-assisted analysis of pydantic/monty@adc986b362 (2026-09-13).
Data as JSON: /api/errors/cd6178d4a9c08d9a.
Report an issue: GitHub.