Assert but only in paranoid mode

Explain
21

Ha, i like the catch unreachable because that’s really a oneliner.
And yes, my tech_check is meant as an assert. A lowlevel miles deep bits and bytes logic bug catch, which should never ever happen.

22

The function is called somehow in releasemode. no catch unreachable possible.

23

if you’re talking about tech_check ofc it is there is no logic stopping it from being called in fast or small modes.
you need to add that yourself, unfortunately zig doesnt have a way to get if runtime safety is on or off, which would be much better than checking the build mode.

24

Yeah I added some stuff to be absolutely sure.

pub inline fn not_in_releasemode() void
{
    comptime if (is_release) @compileError("Don't do this in release mode");
}

pub fn isOk(error_union: anytype) bool
{
    not_in_releasemode();
    return !std.meta.isError(error_union);
}

pub fn tech_check(...) BoardError!void
{
    lib.not_in_releasemode();
    // do stuff..
}

and use it like this:

 assert(lib.isOk(tech_check(...));

edit: unfortunately I don’t get any info on which error occurred. anyway… the assert question is solved for me.

25

you should get an error trace, though it will be less helpful in release safe as there is less debug info

26

the error trace in debugmode stops at assert. But in my is_ok I can get the info.

thread 1752 panic: reached unreachable code
C:\zig\zig-windows-x86_64-0.14.0\lib\std\debug.zig:522:14: 0x7ff697b2917d in assert (main.exe.obj)
    if (!ok) unreachable; // assertion failure
             ^
C:\Data\zig\scrabble\src\tests.zig:119:15: 0x7ff697ba39d0 in test_movegenerator (main.exe.obj)
        assert(lib.is_ok(board.tech_check(mapping)));
              ^
C:\Data\zig\scrabble\src\main.zig:89:38: 0x7ff697ba4ffb in main (main.exe.obj)
    try uses.tests.test_movegenerator(&graph);
                                     ^
C:\zig\zig-windows-x86_64-0.14.0\lib\std\start.zig:475:53: 0x7ff697ba526f in WinStartup (main.exe.obj)
    std.os.windows.ntdll.RtlExitUserProcess(callMain());
27

ah it will probably be more helpful if you use catch unreachable

edit: it doesnt have a error trace at all, thats just the stack trace, probably cause it doesnt know its cause by an error

28

true… i never fetched an error trace. will look for its what and how

29

you dont need to get the error trace yourself the compiler should give you with catch unreachable.

though you could if you wanted…

30

But you can get it with @errorReturnTrace, if you want it.

2 Likes