9
Handling of unlikely syscall errors (programming.dev)
submitted 1 year ago by to c/programming@programming.dev
10 comments fedilink hide all child comments
 

If you were designing a standard library of a high level language (like Rust, C++, etc.) what would it do if while getting the current time of day (e.g. SystemTime::now()) it encountered a failed kernel system call (e.g. to clock_gettime) and why?

What do you think the existing implementations do?

  • Return error or raise exception
  • Return 0
  • Return undefined values (like stack garbage)
  • Panic/crash/segfault
you are viewing a single comment's thread
view the rest of the comments
[–] 5 points 1 year ago (1 child)

Raising an exception would be standard practice, IMO. A library should not dictate how an application behaves. Let the application handle it.

  • permalink
  • fedilink
  • source
  • hideshow 1 child comment
    •
  • [–] 0 points 1 year ago

    If that's the only error mechanism, sure. Exceptions in most languages tend to be relatively expensive, though, and most have a cheaper idiomatic way of returning error codes; you'd want to use those if they're available, right?

    Does Rust use exceptions a lot? I don't know. V has panic and catch, but you almost never see them. Idiomatic is Option (?) and Return (!) values, which I thought V borrowed from Rust. Go does the (val, error) tuple-ish return thing, and while it too has catchable panics, they're discouraged in favor of (error) return values.

    Depends on the language. "Higher level" is a pretty broad field!

  • permalink
  • fedilink
  • source
  • parent