mirror of
https://github.com/lightpanda-io/browser.git
synced 2026-02-04 14:33:47 +00:00
Move more asserts to custom asserter.
Deciding what should be an lp.assert, vs an std.debug.assert, vs a debug-only assert is a little arbitrary. debug-only asserts, guarded with an `if (comptime IS_DEBUG)` obviously avoid the check in release and thus have a performance advantage. We also use them at library boundaries. If libcurl says it will always emit a header line with a trailing \r\n, is that really a check we need to do in production? I don't think so. First, that code path is checked _a lot_ in debug. Second, it feels a bit like we're testing libcurl (in production!)..why? A debug-only assertion should be good enough to catch any changes in libcurl.
This commit is contained in:
@@ -18,6 +18,7 @@
|
||||
|
||||
const std = @import("std");
|
||||
const js = @import("js.zig");
|
||||
const lp = @import("lightpanda");
|
||||
const log = @import("../../log.zig");
|
||||
|
||||
const v8 = js.v8;
|
||||
@@ -743,7 +744,9 @@ pub const Accessor = struct {
|
||||
defer caller.deinit();
|
||||
|
||||
const info = FunctionCallbackInfo{ .handle = handle.? };
|
||||
std.debug.assert(info.length() == 1);
|
||||
if (comptime IS_DEBUG) {
|
||||
lp.assert(info.length() == 1, "bridge.setter", .{ .len = info.length() });
|
||||
}
|
||||
|
||||
caller.method(T, setter, info, .{
|
||||
.as_typed_array = opts.as_typed_array,
|
||||
|
||||
Reference in New Issue
Block a user