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:
Karl Seguin
2026-01-19 09:12:16 +08:00
parent 9b000a002e
commit a6e7ecd9e5
31 changed files with 204 additions and 110 deletions

View File

@@ -17,13 +17,15 @@
// along with this program. If not, see <https://www.gnu.org/licenses/>.
const std = @import("std");
const lp = @import("lightpanda");
const log = @import("../../log.zig");
const js = @import("../../browser/js/js.zig");
const Page = @import("../../browser/Page.zig");
const timestampF = @import("../../datetime.zig").timestamp;
const Notification = @import("../../Notification.zig");
const log = @import("../../log.zig");
const js = @import("../../browser/js/js.zig");
const v8 = js.v8;
const v8 = js.v8;
const Allocator = std.mem.Allocator;
pub fn processMessage(cmd: anytype) !void {
@@ -142,7 +144,7 @@ fn close(cmd: anytype) !void {
const target_id = bc.target_id orelse return error.TargetNotLoaded;
// can't be null if we have a target_id
std.debug.assert(bc.session.page != null);
lp.assert(bc.session.page != null, "CDP.page.close null page", .{});
try cmd.sendResult(.{}, .{});