• @[email protected]
    link
    fedilink
    English
    22 days ago

    I disagree with this. Stack traces are a lazy way to handle errors. They are useful only to the developer of an application for logic errors and bugs in the program. That is their one usecase and are very handy at that usecase.

    For instance the very stack trace he gives us:

    Traceback (most recent call last):
      File "/home/piku/.piku/envs/wikdict/lib/python3.11/site-packages/flask/app.py", line 1511, in wsgi_app
        response = self.full_dispatch_request()
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      File "/home/piku/.piku/envs/wikdict/lib/python3.11/site-packages/flask/app.py", line 919, in full_dispatch_request
        rv = self.handle_user_exception(e)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      File "/home/piku/.piku/envs/wikdict/lib/python3.11/site-packages/flask/app.py", line 917, in full_dispatch_request
        rv = self.dispatch_request()
             ^^^^^^^^^^^^^^^^^^^^^^^
      File "/home/piku/.piku/envs/wikdict/lib/python3.11/site-packages/flask/app.py", line 902, in dispatch_request
        return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)  # type: ignore[no-any-return]
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      File "/home/piku/.piku/apps/wikdict/wikdict_web/lookup.py", line 119, in lookup
        if r := get_combined_result(lang, other_lang, query):
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      File "/home/piku/.piku/apps/wikdict/wikdict_web/lookup.py", line 91, in get_combined_result
        conn = get_conn(lang + "-" + other_lang)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      File "/home/piku/.piku/apps/wikdict/wikdict_web/base.py", line 103, in get_conn
        raise sqlite3.OperationalError(
    sqlite3.OperationalError: Database file "/home/piku/.piku/data/wikdict/dict/en-ko.sqlite3" does not exist
    

    Assuming that is related to a user input this could just be

    Error: Database file "/home/piku/.piku/data/wikdict/dict/en-ko.sqlite3" does not exist.
    

    Even better to give suggestions on how the user might want to fix that problem. Everything else in that stack trace is useless noise that looks scary and takes far more time to parse and get the useful into to users of the program. Stacktraces are just as bad as not adding context to input/environmental errors, maybe only marginally better for the developer. But no user should EVER see a stacktrace and IMO any stacktrace seen should indicate a bug in the application. They are a developers tool, not a way to show users an error message.

    Don’t be lazy and add context and print out your errormessages in a way that is useful to the users of your application. A stacktrace is not that.


    And on the side of stacktraces, they can be more noisy then necessary even for a developer. Here span traces can be useful to find the source of an error without needing to print out the current stack trace which is often vastly less useful in async contexts or other things that are not strictly a straight forward nested call stack.

    • @[email protected]
      link
      fedilink
      English
      111 hours ago

      Collecting the traces can cost some performance, but that is a small price to pay for the advantages and could even be turned off in production builds.

      They clearly intend this post for developers.

      But yeah I want my stacktraces… in my IDE/debugger where I can see them and jump the stack. Most of the time I just need the head, where the breakpoint (or crash) is.

      They also complain about rust where you can RUST_BACKTRACE=1 <program>. The default error tells you so !