Hacker News Reader

Comment by bob1029 | Hacker News Reader

Exceptions can even work with remote APIs.

If you reach into the enterprise bucket of tricks, technologies like WCF/SOAP can propagate these across systems reliably. You can even forward the remote stack traces by turning on some scary flags in your app.config. When printing the final exception using .ToString(), this creates a really magical narrative of what the fuck happened.

The entire reason exceptions are good is because of stack traces. It is amazing to me how many developers do not understand that having a stack trace at the exact instant of a bad thing is like having undetectable wall hacks in a competitive CS:GO match.

View on HN

Yes, I've never quite understood the "But with exceptions it's hard to debug why the error occurred after the fact, its better to be explicit in advance" - The stack trace points exactly to the line. And usually, with the error message and context, its all I need. Maybe I'm missing something that someone can inform me.

Yeah, this kinda becomes a problem when the library you are using does not distribute its source code, so even if you get the line, this information is practically useless to you.

This has been my biggest problem with exceptions, one, for the reason outlined above, plus it's for how much time you actually end up spending on figuring out what the exception for a certain situation is. "Oh you're making a database insertion, what's the error that's thrown if you get a constraint violation, I might want to handle that". And then it's all an adventure, because there's no way to know in advance. If the docs are good it's in the docs, otherwise "just try it" seems to be the way to do it.

Yeah I agree with that, opaque errors from libraries are where this really sucks. The worst is when they swallow the original error and throw a generic exception instead.

I think the real issue here is the lack of checked exceptions in most runtimes that use them. If you had compiler support for what’s thrown you would know in advance. Java has them, but they haven’t made them usable syntactically so programmers have rallied against them and any investment in that area is unpopular.

Many "developers" think print("OOOPS") is a good way to debug - so I guess it's an education problem.

> It is amazing to me how many developers do not understand that having a stack trace at the exact instant of a bad thing is like having undetectable wall hacks in a competitive CS:GO match.

Who doesn't understand that? If you aren't using exceptions you are using wrapping instead, and said wrapping is merely an alternative representation of what is ultimately the very same thing. This idea isn't lost on anyone, even if they don't use the call stack explicitly.

The benefit of wrapping over exceptions[1] is that each layer of the stack gains additional metadata to provide context around the whole execution. The tradeoff is that you need code at each layer in the stack to assign the metadata instead of being able to prepare the data structure all in one place at the point of instantiation.

[1] Technically you could wrap exceptions in exceptions, of course. This binary statement isn't quite right, but as exceptions have proven to be useless if you find yourself ending up here, with two stacks offering the same information, we will assume for the sake of discussion that the division is binary.

One could say the whole point of wrapping exceptions is to add additional metadata _if such data is available_. Otherwise, the most basic metadata is tracked automatically: stack locations.

Technically, the actual whole point of wrapping is to avoid leaking implementation details. If you let "FooLibraryException" bubble up, and then you stop using Foo Library, then all of the users of your code are going to end up broken waiting for "FooLibraryException" when now you throw "BarLibraryException". This diminishes any value exception handlers theoretically could provide since you end up having to wrap everything at each step anyway.

Checked exceptions were introduced to try to help with that problem, giving you at least a compiler error if an implementation changed from underneath you. But that comes with its own set of problems and at this point most consider it to be a bad idea.

Of course, many just throw caution to the wind and don't consider the future, believing they'll have moved on by then and it will be the next programmer's problem. Given the context of discussion, we have assumed that is the case.

Reply on news.ycombinator.com