aboutsummaryrefslogtreecommitdiffhomepage
path: root/notes/runtime_exceptions.txt
blob: 214335e2e1ccd909e409fcc64980c26aa25b4349 (plain)
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
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78

Annotations of Runtime Exceptions
=================================

We want operations that can fail at runtime to stand out, or at least be
visible in the source code.

Note: This is different from "unsafe" in other langauges. This simply means
that some piece of code can do the SLUL equivalent of "throwing exception".

Here are some risky operations:
- dereference of optional pointer
- (maybe also comparison of optional pointer?except for constant "none" value)
- array index
- division
- integer overflow
- integer underflow
- stack overflow?
-- module-local function which can call other module-local function which can (possibly indirectly) call the first function, or
-- module-local function which can call function in a module that (possibly indirectly) depends on this module,
--- how can the compiler know this without checking recursively?
--- perhaps a special flag for \depends?
- out of memory (=when allocating, but possibly also when accessing memory when using over-commit)

Syntax with "?":
 # optional ptr dereference
 b = bp?
 # array indexing
 # (this syntax is kind of hard/non-obvious)
 b = arr[?i]
 # (this syntax is ambiguous)
 b = arr[i]?
 # division
 r = p /? q
 r /?= q
 # addition
 r +?= 1

Syntax with blocks:
 # optional ptr dereference
 risky none_deref {
     b = bp
 }
 # array indexing
 risky array_out_of_bounds {
     b = arr[i]
 }
 # division
 risky div_by_zero {
     r = p / q
     r /= q
 }
 # addition
 risky integer_overflow {
     x += 1
 }
 # allocation
 risky alloc {
     obj = .new()
 }

I prefer the block syntax over "?", because it is more flexible/extensible,
and it also stands out much more.

This should *not* be added to functions, because that would cause a
"function color" problem, where "risky" functions cannot be called by non-
risky ones.
- also, all RuntimeException's in Java are unchecked exceptions.

What keyword is best?
- risky:  short, but maybe this sounds a bit too risky ;)
- throw:  this is good (for Java programmers at least)
- except: sounds wrong
- exception: but exceptions cannot be catched (except by creating a separate arena)
- canfail: most descriptive?

 exception integer_overflow {
    x += 1
 }