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
  • Eager Eagle@lemmy.worldEnglish
    8·
    15 days ago

    you should do what’s idiomatic for that language, e.g.: return an error in Rust; raise an exception in Python or Java; return an integer != 0 in C; etc.

    Panic/crash/segfault

    probably the worst option for a library

    • senkora@lemmy.zip
      5·
      15 days ago

      +1. If your library makes it impossible to recover from errors, then it will be unusable from any program that requires recovering from errors.

    • hadesOP
      2·
      15 days ago

      probably the worst option for a library

      Even worse than returning garbage? :)

      • Eager Eagle@lemmy.worldEnglish
        2·
        15 days ago

        If it’s garbage as in a string with a bunch of information that is hard to parse, yeah, crashing without giving the caller a way to avoid it might be worse. But what is exactly this garbage and in what cases are you considering returning it at all?

        • hadesOP
          1·
          15 days ago

          Uninitialized automatic variables. E.g. (in C/C++):

          int get_time() {
  int time;
  syscall(/* something that fails */, &time);
  return time;
}
  • Colloidal
    6·
    15 days ago

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

    • 𝕽𝖚𝖆𝖎𝖉𝖍𝖗𝖎𝖌𝖍@midwest.socialEnglish
      11·
      15 days 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!

      • bleistift2@sopuli.xyzEnglish
        3·
        15 days 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?

        I think not being able to get the current time from the system is very exceptional. And I think exceptional circumstances should act that way and not “look like” normal executions. To me, that means letting hell break loose, and not “silently” return a 1 instead of a 0.

        By similar reasoning, “Exceptions in most languages tend to be relatively expensive” is a very weak argument. We don’t expect this error-throwing code to execute a lot.

  • Treczoks@lemmy.world
    3·
    15 days ago

    Return an error, respectively, in a language that supports it, raise an exception.

    In my systems, nearly every call returns a status, and it is advisable to check this status. I had a number of long calls with windows programmers who complained about my system failing at some point, and most often, the reason was an ignored Non-OK status return at some point in the past.

    Like “Your system loses the file I’m writing!”. FileSystem_Open() returned a non-OK value (I don’t remember the reason, but there was one). FileSystem_Write() returned a non-OK value (file pointer invalid). FileSystem_Close() returned a non-OK value (file pointer invalid). And he complains about a file that is not there…

  • anton@lemmy.blahaj.zone
    2·
    15 days ago

    I think you should make the overwhelmingly likely case crash in a controlled way, but provide a way to handle it for people who truly want to keep going in such strange conditions.

    In rust I would panic in now(), but also provide a alternative call that returns a result named something like try_now(), similar to Vec::with_capacity and Vec::try_with_capacity.
    In languages that provide them, you could also throw a runtime exception that can be ignored and just bubbles up to main unless explicitly caught.

  • HaraldvonBlauzahn@feddit.org
    1·
    15 days ago

    For Rust, return Result<> , as is idomatic in Rust.

    Another possible method is having an installable handler that handles the error at the place it is detected. Common Lisp does that and it is very powerful.