Exceptions in BPF

Posted Jul 22, 2023 8:42 UTC (Sat) by jezuch (subscriber, #52988)
In reply to: Exceptions in BPF by Cyberax
Parent article: Exceptions in BPF

Maybe this thould be renamed as "panic", because it's doing the same thing as panic in Rust. These are no generic exceptions.

Exceptions in BPF

Posted Jul 22, 2023 9:15 UTC (Sat) by softball (guest, #160655) [Link] (3 responses)

A core difference is: BPF looks to treat throws as success-by-default (rc 0), Rust panics are failure-by-default. Rust panics have to be caught explicitly. My experience with Rust is limited so far, but catching panics seems rare and unidiomatic: there's already featureful error handling available (Result type), so any panics are usually serious enough to not be handlable.

Exceptions in BPF

Posted Jul 23, 2023 7:35 UTC (Sun) by xi0n (subscriber, #138144) [Link] (2 responses)

Panics in idiomatic Rust are only caught to prevent them from crossing an FFI boundary, i.e. escaping a Rust callback that’s been called from C. Otherwise, programs can set a global panic handler if the standard one is inadequate, but that is only really used for embedded and other no_std environments.

This saying, the mechanism proposed here is so close to Rust panics (and Go panics) that NOT calling it such will only lead to confusion, esp. when “exception” is such an overloaded term already.

Exceptions in BPF

Posted Jul 25, 2023 6:59 UTC (Tue) by taladar (subscriber, #68407) [Link]

Setting a custom panic handler is also frequently used in situations where the panic should be logged before exiting.

Exceptions in BPF

Posted Nov 5, 2023 13:03 UTC (Sun) by ibukanov (subscriber, #3942) [Link]

Go panics are exactly the exceptions. They can be caught at arbitrary points and can pass arbitrary values across the stack.

Exceptions in BPF

Posted Jul 22, 2023 12:07 UTC (Sat) by dezgeg (subscriber, #92243) [Link] (1 responses)

Sounds it would be too confusing when 'Kernel panic' is already a thing

Exceptions in BPF

Posted Jul 23, 2023 18:48 UTC (Sun) by rqosa (subscriber, #24136) [Link]

Maybe naming it "error" (or something like that) would be a reasonable choice that isn't too similar to those 2 other terms?

(Java uses the word "error" in a similar sense in java.lang.Error's name — i.e. for "serious problems that a reasonable application should not try to catch".)