4 ms·

You know why I hate exceptions most? When debugging be it C# or JS, neither the "break on all exceptions" or "break on caught exceptions" are useful on any app

You know why I hate exceptions most? When debugging be it C# or JS, neither the "break on all exceptions" or "break on caught exceptions" are useful on any app. One just hits random library shit, or whatever bloat is in the codebase all the time and the other won't break at all. But because exceptions are the control flow that is the only way to debug them (or do a human binary search) Not sure what go debugging is like but I imagine you can quickly work your way to the first err!=nil while debugging.

7bit 2y ago
You can limit those to code you write. But it sounds like you break also on code that you didn't write eg, libraries or modules. Of course you're miserable.
- aqueueaqueue 2y ago
  Tell me the dev console option to not do that and I'll use it. I admit it has been a while since I front ended.
sapiogram 2y ago
The go standard library also recovers from panics internally in some places, for example for gradient descent parsers.
rs186 2y ago
Well, "break on exceptions" can be very powerful when used correctly, i.e. when the scope is narrowed down. It should never be a flag that is turned on all the time -- that's guaranteed misery there. > quickly work your way to the first err != nil while debugging I doubt you'll spend any less time debugging in Go. If you disagree, I'd love to see a "side-by-side" comparison for code that's functionally the same but written in both Go and JS, and see some explanations why it's easier in Go
- BobbyJo 2y ago
  I've shipped code in JS, Python, C++, Java, Golang, and a few others. I can say with certainty Golang was the easiest to debug simply because if a layer could fail, it was explicitly obvious. Exceptions might come from a few layers deep, and you don't know that until one gets raised.
  - rs186 2y ago
    Like I said, an example would be 100% more effective and convincing than your personal experience here.
mrighele 2y ago
I don't know about C#, but in my Java IDE when I set a breakpoint on an exception I can set a filter not only on the class being throw, but also on the class that catch it, the one that throws it and the caller method, and to trigger only after another breakpoint is hit or it is the nth times it has been passed. With this you can make it trigger only when needed in a farly easy way
- CharlieDigital 2y ago
  It's the same for the mainstream debuggers for .NET.
  - aqueueaqueue 2y ago
    But if that class is thrown again and again it is less useful which I see in a lot of codebases. The go equivalent is "catch the exception when it happens here" A debugger feature for that would be nice. I guess it is a debugger concern not an exceptions issue per se.
    - CharlieDigital 2y ago
      There is a `justMyCode` option even in VSC: https://code.visualstudio.com/docs/csharp/debugger-settings#_just-my-code https://code.visualstudio.com/docs/csharp/debugger-settings#...
    - PeeMcGee 2y ago
      Conditional breakpoints exist in Intellij and work well with Java in my experience. You craft a little boolean expression on the breakpoint that references variables in-scope, and the debugger skips the breakpoint unless the expression evaluates to true. Every time I've used this feature has been one of the darkest times of my life.
      - renewiltord 2y ago
        It also slows down execution so much. Agreed that it is a dark day if I'm forced to use that. If it's not in library code I just put the condition in an if and put the breakpoint inside it.
jcelerier 2y ago
That's very opposite from my experience in c++. Enabling break on throw in gdb or lldb always brings me exactly where I need to be no matter the OS / platform. But the software in c++ pretty much always adheres to "exceptions only for exceptional circumstances" and thankfully let them bubble up without rethrow à la java, otherwise it would be absolutely terrible developer ux
Someone 2y ago
> Not sure what go debugging is like but I imagine you can quickly work your way to the first err!=nil while debugging. How do you imagine that happening? I can’t see another way then either stepping through your code or setting breakpoints on all the ‘return nil, err’ statements. You rarely, if ever, can use a ‘watch variable’ feature, because each function will have its own local ‘err’, and will have a new one on each invocation. If, instead of ‘return buil, err’, there’s ‘throw new…’ in such blocks, I don’t see why you couldn’t do the same things.
- djfivyvusn 2y ago
  [dead]

7bit 2y ago

You can limit those to code you write. But it sounds like you break also on code that you didn't write eg, libraries or modules. Of course you're miserable.

aqueueaqueue 2y ago
Tell me the dev console option to not do that and I'll use it. I admit it has been a while since I front ended.

sapiogram 2y ago

The go standard library also recovers from panics internally in some places, for example for gradient descent parsers.

rs186 2y ago

Well, "break on exceptions" can be very powerful when used correctly, i.e. when the scope is narrowed down. It should never be a flag that is turned on all the time -- that's guaranteed misery there. > quickly work your way to the first err != nil while debugging I doubt you'll spend any less time debugging in Go. If you disagree, I'd love to see a "side-by-side" comparison for code that's functionally the same but written in both Go and JS, and see some explanations why it's easier in Go

BobbyJo 2y ago
I've shipped code in JS, Python, C++, Java, Golang, and a few others. I can say with certainty Golang was the easiest to debug simply because if a layer could fail, it was explicitly obvious. Exceptions might come from a few layers deep, and you don't know that until one gets raised.
- rs186 2y ago
  Like I said, an example would be 100% more effective and convincing than your personal experience here.

mrighele 2y ago

I don't know about C#, but in my Java IDE when I set a breakpoint on an exception I can set a filter not only on the class being throw, but also on the class that catch it, the one that throws it and the caller method, and to trigger only after another breakpoint is hit or it is the nth times it has been passed. With this you can make it trigger only when needed in a farly easy way

CharlieDigital 2y ago
It's the same for the mainstream debuggers for .NET.
- aqueueaqueue 2y ago
  But if that class is thrown again and again it is less useful which I see in a lot of codebases. The go equivalent is "catch the exception when it happens here" A debugger feature for that would be nice. I guess it is a debugger concern not an exceptions issue per se.
  - CharlieDigital 2y ago
    There is a `justMyCode` option even in VSC: https://code.visualstudio.com/docs/csharp/debugger-settings#_just-my-code https://code.visualstudio.com/docs/csharp/debugger-settings#...
  - PeeMcGee 2y ago
    Conditional breakpoints exist in Intellij and work well with Java in my experience. You craft a little boolean expression on the breakpoint that references variables in-scope, and the debugger skips the breakpoint unless the expression evaluates to true. Every time I've used this feature has been one of the darkest times of my life.
    - renewiltord 2y ago
      It also slows down execution so much. Agreed that it is a dark day if I'm forced to use that. If it's not in library code I just put the condition in an if and put the breakpoint inside it.

jcelerier 2y ago

That's very opposite from my experience in c++. Enabling break on throw in gdb or lldb always brings me exactly where I need to be no matter the OS / platform. But the software in c++ pretty much always adheres to "exceptions only for exceptional circumstances" and thankfully let them bubble up without rethrow à la java, otherwise it would be absolutely terrible developer ux

Someone 2y ago

> Not sure what go debugging is like but I imagine you can quickly work your way to the first err!=nil while debugging. How do you imagine that happening? I can’t see another way then either stepping through your code or setting breakpoints on all the ‘return nil, err’ statements. You rarely, if ever, can use a ‘watch variable’ feature, because each function will have its own local ‘err’, and will have a new one on each invocation. If, instead of ‘return buil, err’, there’s ‘throw new…’ in such blocks, I don’t see why you couldn’t do the same things.

djfivyvusn 2y ago
[dead]