4 ms·

But no context, so in the real world you need to write: try: f = open('foo.txt', 'w') except Exception as e: raise NecessaryContext("im

by 9rx 11mo ago

But no context, so in the real world you need to write: try: f = open('foo.txt', 'w') except Exception as e: raise NecessaryContext("important information") from e Else your callers are in for a nightmare of a time trying to figure out why an exception was thrown and what to do with it. Worse, you risk leaking implementation details that the caller comes to depend on which will also make your own life miserable in the future.

tayo42 11mo ago
How is a stack trace with line numbers and a message for the exception it self not enough information for why an exception was thrown? The exceptions from something like open are always pretty clear. Like, the files not found, and here is the exact line of code and the entire call stack. what else do you want to know to debug?
- 9rx 11mo ago
  It's enough information if you are happy to have a fragile API, but why would you purposefully make life difficult not only for yourself, but the developers who have their code break every time you decide to change something that should only be an internal implementation detail? Look, if you're just writing a script that doesn't care about failure — where when something goes wrong you can exit and let the end user deal with whatever the fault was, you don't have to worry about this. But Go is quite explicitly intended to be a systems language, not a scripting language. That shit doesn't fly in systems. While you can, of course, write systems in Python, it is intended to be a scripting language, so I understand where you are coming from thinking in terms of scripts, but it doesn't exactly fit the rest of the discussion that is about systems.
  - tayo42 11mo ago
    That makes even less sense becasue go errors provide even less info other then a chain of messages. They might as well be lists of strings. You can maybe reassbmle a call stack your self if all of the error handlers are vigalente about wrapping
    - 9rx 11mo ago
      > That makes even less sense becasue go errors provide even less info other then a chain of messages. That doesn't make sense. Go errors provide exactly whatever information is relevant to the error. The error type is an interface for good reason. The only limiting bound on the information that can be provided is by what the computer can hold at the hardware level. > They might as well be lists of strings. If a string is all your error is, you're doing something horribly wrong. Or, at very least, are trying to shoehorn Go into scripting tasks, of which it is not ideally suited for. That's what Python is for! Python was decidedly intended for scripting. Different tools for different jobs. Go was never designed to be a scripting language. But should you, for some odd reason, find a reason to use in that that capacity, you should at least being using its exception handlers (panic/recover) to find some semblance of scripting sensibility. The features are there to use. Which does seem to be the source of your confusion. You still seem hung up on thinking that we're talking about scripting. But clearly that's not true. Like before, if we were, we'd be looking at using Go's exception handlers like a scripting language, not the patterns it uses for systems. These are very different types of software with very different needs. You cannot reasonably conflate them.
      - tayo42 11mo ago
        Chill with being condescending if you want a discussion. The error type in go is literally just a string type error interface { Error() string } That's the whole thing. So i dont know what your talking about then. The wrapped error is a list of error types. Which all include a string for display. Displaying an error is how you get that information to the user. If you implement your own error, and check it with some runtime type assertion, you have the same problem you described in python. Its a runtime check, the API your relying on in whatever library can change the error returned and your code won't work anymore. The same fragile situation you say exists in python. Now you have even less information, theres no caller info.
        9rx 11mo ago
        > The error type in go is literally just a string No, like I said before, it's literally an interface. Hell, your next line even proves it. If it were a string, it would be defined as: type error string But as you've pointed out yourself, that's not its definition at all. > So i dont know what your talking about then. I guess that's what happens when you don't even have a basic understanding of programming. Errors are intended to be complex types; to capture all the relevant information that pertains to the error. https://go.dev/play/p/MhQY_6eT1Ir https://go.dev/play/p/MhQY_6eT1Ir At very least a sentinel value. If your error is just a string, you're doing something horribly wrong — or, charitably, trying to shoehorn Go into scripting tasks. But in that case you'd use Go's exception handlers, which bundles the stack trace and all alongside the string, so... However, if your workload is script in nature, why not just use Python? That's what it was designed for. Different tools for different jobs.
- arccy 11mo ago
  like why did the program even choose to open this file? a stack trace is useless if your code is even a little bit generic

by 9rx 11mo ago

tayo42 11mo ago

How is a stack trace with line numbers and a message for the exception it self not enough information for why an exception was thrown? The exceptions from something like open are always pretty clear. Like, the files not found, and here is the exact line of code and the entire call stack. what else do you want to know to debug?

9rx 11mo ago
It's enough information if you are happy to have a fragile API, but why would you purposefully make life difficult not only for yourself, but the developers who have their code break every time you decide to change something that should only be an internal implementation detail? Look, if you're just writing a script that doesn't care about failure — where when something goes wrong you can exit and let the end user deal with whatever the fault was, you don't have to worry about this. But Go is quite explicitly intended to be a systems language, not a scripting language. That shit doesn't fly in systems. While you can, of course, write systems in Python, it is intended to be a scripting language, so I understand where you are coming from thinking in terms of scripts, but it doesn't exactly fit the rest of the discussion that is about systems.
- tayo42 11mo ago
  That makes even less sense becasue go errors provide even less info other then a chain of messages. They might as well be lists of strings. You can maybe reassbmle a call stack your self if all of the error handlers are vigalente about wrapping
  - 9rx 11mo ago
    > That makes even less sense becasue go errors provide even less info other then a chain of messages. That doesn't make sense. Go errors provide exactly whatever information is relevant to the error. The error type is an interface for good reason. The only limiting bound on the information that can be provided is by what the computer can hold at the hardware level. > They might as well be lists of strings. If a string is all your error is, you're doing something horribly wrong. Or, at very least, are trying to shoehorn Go into scripting tasks, of which it is not ideally suited for. That's what Python is for! Python was decidedly intended for scripting. Different tools for different jobs. Go was never designed to be a scripting language. But should you, for some odd reason, find a reason to use in that that capacity, you should at least being using its exception handlers (panic/recover) to find some semblance of scripting sensibility. The features are there to use. Which does seem to be the source of your confusion. You still seem hung up on thinking that we're talking about scripting. But clearly that's not true. Like before, if we were, we'd be looking at using Go's exception handlers like a scripting language, not the patterns it uses for systems. These are very different types of software with very different needs. You cannot reasonably conflate them.
    - tayo42 11mo ago
      Chill with being condescending if you want a discussion. The error type in go is literally just a string type error interface { Error() string } That's the whole thing. So i dont know what your talking about then. The wrapped error is a list of error types. Which all include a string for display. Displaying an error is how you get that information to the user. If you implement your own error, and check it with some runtime type assertion, you have the same problem you described in python. Its a runtime check, the API your relying on in whatever library can change the error returned and your code won't work anymore. The same fragile situation you say exists in python. Now you have even less information, theres no caller info.
      - 9rx 11mo ago
        > The error type in go is literally just a string No, like I said before, it's literally an interface. Hell, your next line even proves it. If it were a string, it would be defined as: type error string But as you've pointed out yourself, that's not its definition at all. > So i dont know what your talking about then. I guess that's what happens when you don't even have a basic understanding of programming. Errors are intended to be complex types; to capture all the relevant information that pertains to the error. https://go.dev/play/p/MhQY_6eT1Ir https://go.dev/play/p/MhQY_6eT1Ir At very least a sentinel value. If your error is just a string, you're doing something horribly wrong — or, charitably, trying to shoehorn Go into scripting tasks. But in that case you'd use Go's exception handlers, which bundles the stack trace and all alongside the string, so... However, if your workload is script in nature, why not just use Python? That's what it was designed for. Different tools for different jobs.
arccy 11mo ago
like why did the program even choose to open this file? a stack trace is useless if your code is even a little bit generic