Error -> Defect for defects (#13908)
* Error -> Defect for defects The distinction between Error and Defect is subjective, context-dependent and somewhat arbitrary, so when looking at an exception, it's hard to guess what it is - this happens often when looking at a `raises` list _without_ opening the corresponding definition and digging through layers of inheritance. With the help of a little consistency in naming, it's at least possible to start disentangling the two error types and the standard lib can set a good example here.
This commit is contained in:
parent
cd9af6b804
commit
7d6cbf290a
92 changed files with 323 additions and 300 deletions
|
|
@ -88,7 +88,7 @@
|
|||
##
|
||||
## test "out of bounds error is thrown on bad access":
|
||||
## let v = @[1, 2, 3] # you can do initialization here
|
||||
## expect(IndexError):
|
||||
## expect(IndexDefect):
|
||||
## discard v[4]
|
||||
##
|
||||
## echo "suite teardown: run once after the tests"
|
||||
|
|
@ -190,7 +190,7 @@ proc delOutputFormatter*(formatter: OutputFormatter) =
|
|||
|
||||
proc resetOutputFormatters* {.since: (1, 1).} =
|
||||
formatters = @[]
|
||||
|
||||
|
||||
proc newConsoleOutputFormatter*(outputLevel: OutputLevel = OutputLevel.PRINT_ALL,
|
||||
colorOutput = true): <//>ConsoleOutputFormatter =
|
||||
ConsoleOutputFormatter(
|
||||
|
|
@ -717,7 +717,7 @@ macro expect*(exceptions: varargs[typed], body: untyped): untyped =
|
|||
## of 3: raise newException(IOError, "I can't do that Dave.")
|
||||
## else: assert 2 + 2 == 5
|
||||
##
|
||||
## expect IOError, OSError, ValueError, AssertionError:
|
||||
## expect IOError, OSError, ValueError, AssertionDefect:
|
||||
## defectiveRobot()
|
||||
let exp = callsite()
|
||||
template expectBody(errorTypes, lineInfoLit, body): NimNode {.dirty.} =
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue