Hacker News Reader

Comment by aqueueaqueue | Hacker News Reader

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.

View on HN

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

It's the same for the mainstream debuggers for .NET.

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.

There is a `justMyCode` option even in VSC: https://code.visualstudio.com/docs/csharp/debugger-settings#...

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.

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.

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

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.

Like I said, an example would be 100% more effective and convincing than your personal experience here.

> 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.

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

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.

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.

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

Reply on news.ycombinator.com