1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
|
Thread-local or arena-local "error reference".
* Could have per-module error number, error name,
additional information (e.g. filename, line number, etc.)
* Arena could have some space reserved for allocating errors.
* Is it necessary to copy data? Or are references fine?
Resources might get free'd, but everything else should be OK
to reference.
Asynchronous errors:
* Continuing to do things on a "failed" object (e.g. a file that
wasn't found) should not give repeated errors.
- However, there could be loops where the code could get stuck,
so errors must eventually be "materialized".
- In a system with user-space controlled "timeslice start", this could
be done at the start of the timeslice (before delegating to the real
task).
- In a system with threads, this could be a "not-on-idle" background
thread that checks the error flag (of any thread) every millisecond or
so, and materializes the error (and/or terminates the failed thread).
This thread would pause when there are no running threads.
Errors in return values:
* This could be an "additional `none` value". Like Zig error enums, but
with only one value.
* In the SysV and Win32/64 ABIs, this could be represented by the value
`(void *)-1`
* On platforms that use the carry flag to indicate error (e.g. BSD, but also
some really old OS'es like DOS), this error value could be indicated
with the carry flag (perhaps combined with a -1 return value).
Syntax for function declarations involving errors and optional values:
func a
returns
Thing
end
func b
returns
optional Thing
end
func c
returns
optional Thing
errors
KeyNotFound
exceptions
OutOfMemory
end
|
