Comment by fxtentacle | Hacker News Reader

Comment by fxtentacle | Hacker News Reader

Oh, how often I wish that someone would have followed this advice.

Working mostly on Java these days, Carmack's focus on efficiently doing the right thing sounds like fairy-tales of the promised land ;)

Just yesterday, I spent much longer than I believe is reasonable to fix a bug in a Java class whose sole purpose is to do an HTTP(S) call and determine if the URL is online (200 code) or declared offline (40x code).

The first thing that really slowed me down was that instead of having a clear location for the crash, a Java .war inside tomcat tends to vomit 40-50 lines of stack trace onto the console. The reported Exception was "java.io.IOException: Server returned HTTP response code: 400 for URL: ..." in HttpURLConnection.getResponseCode(). But debugging the issue, I noticed that getResponseCode exits just fine without any exception.

A bit of Googling around revealed that the root cause was this: https://stackoverflow.com/a/54837353/525608 Inside getResponseCode(), an exception is thrown, caught, and suppressed. And then later, it is retrieved out of HttpURLConnection.rememberedException and thrown around by a different HttpURLConnection function. But of course the Exception still had the old = wrong stack trace in it. So those 40+ lines of stack trace that Java garbled up? Completely useless.

I kid you not, Java source code with Exceptions is like your own private hell, especially because the control flow tends to be somewhere between "nested inside 30 functions" and "completely random". The latter usually happens when libraries do bytecode patching so that what is actually executed doesn't even match the source code anymore, and that's also the point where stack traces become almost completely useless.

I'd take a 2000+ lines monolithic function every day over this unholy mess that ["Enterprise Java" == stacking random libraries on top of each other] has become.

Just out of curiosity, are there any Java web frameworks with reasonable stack depths? After working on .NET Core codebases for several years (which rarely have more than 4-5 calls within the framework itself) I was shocked to see stack dumps from a Spring application I've been working on. Three to four nested exceptions, with up to 100 nested calls (and sometimes more) within each one. If you don't have a smart IDE folding the less interesting parts (and copious amounts of amphetamine), it's simply unreadable.

Spring is the poster child for abstraction gone wild. Famously: https://docs.spring.io/spring-framework/docs/3.0.6.RELEASE_t...

Haha, I think the worst part of that unintended joke is that the class description starts with Convenient. I wonder if the author of that text noticed how weird the whole thing is?

"Convenient proxy factory bean superclass for proxy factory beans that create only singletons."

in poker, you are sometimes faced with a shitty decision on the river, but the mistake was made preflop

In some future decade, when Banks start trying to migrate their "Enterprise Java" systems, anyone that can make sense of that bizarre and rather absurd model of computation is going to get well compensated.

How many COBOL programmers do you know who drive Ferraris?

None, I guess they didn't make it complicated enough!

Keep in mind that Spring was originally a reaction to the extreme complexity of Enterprise Java. I still remember a talk where they said everything would just be simple POJOs: plain old Java objects.

It was certainly well marketed. But in reality, Spring is also too complex. It has far too much dynamic dispatch, byte-code weaving magic and runtime failure. This is now causing them problems with GraalVM and fast startup times needed for cloud.

There is an architectural error in Java frameworks that I've noticed. (Other languages have it too, just nowhere near as common.)

Basically, the error is that when some system uses virtual function calls via an interface, what that's really saying is that: "This can be changed at runtime."

So if there's some function "void foo( IBar bar )", then what that's really saying is that "bar" can change at runtime. Literally a different implementation from call-to-call.

Is that actually required?

In 99.9% of such function calls, no: the implementation of IBar will always be the same concrete class.

To see a language that has gone to the opposite end of the spectrum, take a look at Rust. It use a lot of parametric typing, which is very flexible, but by default tends to use compile-time static types instead of run-time dynamic types.

Java never went down this path because it added parametric types very late in its design.

C# had parametric types in v2.0, which is when it started getting popular.

Rust had it from the beginning.

For some odd reason, Go still doesn't have parametric types (they call it generics), yet it seems to have remained surprisingly sane despite supporting generic interfaces.

https://golangnews.org/2020/11/experimenting-with-go-type-pa...

Do you have any idea what they did right that Java lacked?

My guess it’s the different idea of what an interface is and how errors are signaled.

An interface in Go can be defined by the client code and types just need to implement the functions. In Java Interfaces need to be defined before any code can use it. And exception handling makes code hard to reason about because it introduces hidden control flow.

I think Generics don’t give you that much leverage. Without them you need to duplicate the code for each type or class, but duplicated code is much easier to work with. Yes, it’s not really dry, but copy paste and search/replace is something which increases developer productivity, fixing bugs in code with too many generics decreases it.

And one thing to keep in mind: historically a lot of interfaces in Java were necessary because Java had no lambdas. In Go functions are first class citizens and you don’t need an Interface just to dynamically call different functions.

The appeal of generics is in writing data structure libraries that are primarily abstract containers. With parametric typing you can bind the contained type early, rather then being bound through runtime indirections and checks like a dynamic type system, handles to another container, interface compatibility, or other such tricks.

That's an important role, especially in performance-sensitive domains, but outside of that, it never seems to work very well, which makes it a easily misused feature in every language I've used that offers it. Go's original design basically took the form of offering this for the built-in structures but not letting you roll your own, ushering you towards interfaces if you really needed it, and because Go makes interfaces convenient, it mostly works.

I agree, the native array and dictionary support in go makes it easy to forget that they don't have generics.

BTW, as an example of generics abuse, crypto++ comes to mind. It's such a huge pile of templates referencing each other and exceptions being used to control the command flow, that I was once hired as a freelancer just to link the whole thing into a static library, because the company using it was unwilling to deal with the source code, but needed it for FIPS compliance.

It's an incredible engineering feat that they managed to let you mix and match cryptographic functions and containers and storage formats as you see fit, but having a C++ stack trace with 5 abstract templates in it makes it very painful to debug if stuff goes wrong.

Thanks for pointing out lambdas. I hadn't considered them, but I wholeheartedly agree :) My go projects tend to have small helper lambdas and lots of defer calls, which are effectively lambdas, too. Without them, I'd need a lot more source code and/or an IDisposable interface for pretty much every io class.

golang is basically Java pre-generics. Working with large golang codebases is quite annoying and error prone, partly due to the lack of generics. They didn't get it right at all.

Having built an offline-capable distributed database in go, I noticed that even "larger" projects in go tend to be a lot less source code than building something similar in Java.

And maybe that's just my personal style, but to me defer is much more important than generics.

I can't even remember how often I've had to debug Java bugs where someone forgot to close a ResultSet for an SQL query... And then you leak memory so badly that restarting tomcat with a daily cron is still not enough :(

With defer, you can expect people to write the cleanup code immediately after opening something, which makes it much easier to confirm that you're not leaking resources.

Java already solved this with try-with-resources, which the linter or IDE can warn you about (because the instance has to inherit from `AutoCloseable`). Not so with golang's defer, where it is much more likely that the developer can forget to call it.

I got a feeling "hardcoded" repeating code is underrated. I work in a code base right now that has alot of configs floating in from everywhere and functions taking function arguments with deep call tree.

I just wish there was long crappy linear functions with inline configs so that I could search this mess and see line by line what it did without having to keep so much in my head.

Maybe it was easier to write but it sure as hell is harder to read ...

Agree. In c++, I really like the JUCE editor exactly because of this. You have a GUI to configure things and it's stored as an xml config, but it'll also autogenerate a header for you with all the constant things hardcoded.

In my opinion, that provides one huge advantage that Java currently lacks: you can use tools like ReSharper to statically analyze control flow, find uninitialized variables or unused branches, etc.

> HttpURLConnection.rememberedException

Something must be quite bad with the design if he ends up having to remember exceptions...

Agreed. This design deserves a moment of leaning back in your chair with your jaw dropped: as if exception handling wasn't awful enough to begin with, this construct completely undermines the whole purpose of it and on top of it adds another layer of complication.

I feel for the poor guy who had to figure out the bug that was caused by this -- the waste of his time was completely predictable by this idiotic design.

I feel like Java('s libraries) forces this kind of exception inception sometimes. But there's a useful way to do it at least: set the original exception as the cause of any new exception thrown, and make sure your exception logger walks the cause chain. You'll have an insanely long stack trace in your logs, but at least it'll be accurate.

> set the original exception as the cause of any new exception thrown

100%, not only did this person make a pretty strange design, he has completely misunderstood how exceptions are to be used. even when he remembers exceptions, he fails to make them the root cause of the new exceptions he throws. truly a remarkable design, in all the wrong ways.

> this construct completely undermines the whole purpose of it

Absolutely, a bad design that says more about the designer of that piece of code, than the language (Java). Error handling can and should be discussed, but I hope people don't use this as an example to illustrate how bad Java checked exceptions are. This is just some nonsense that can be constructed when you misunderstand underlying concepts, which is possible in any language.

Yes. But sadly, that (in retrospect bad) decision has been part of the Java standard library for 20 years now.

Here's a bug report from 2001 where the rememberedException had accidentally changed its behaviour: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4523989

Incredible. It looks like much of the early Java web stuff was so poorly designed, it's baffling that it ever got accepted as part of anything.

* Java Server Faces

* Tag libraries

* Portlets

How did any of this become official Java technology.

My jaw dropped the first time I learned that JSF was translated (not sure compiled is the right word) into Servlets full of print statements. And of course no JSF-based application has ever managed to produce valid well-formed HTML ever since.

It should be noted that you are now referring to the sanest part of Java Server Faces, i.e. its first template system: Java Server Pages or JSP. If think JSP that compiles to a bunch of Servlets filled with print statements is bad, you really have to look at the rest of that stuff; because it gets a lot worse :-)

The stateful design, which fills up templates with a bunch of hidden html-input fields, in order to open web-pages in the same "state" as you left them and all sorts of other crap.

You also need to look into Portlets, which "splits" up a web-pages into seemingly stand-alone components. These are then combined into horribly complicated Servlets as you deploy, where http paramters are namespaced with some random _portletId=lsøjfksjo1920 things in order to figure out which parameters goes to which "part of the web-page". Again, all of this is so bad, you'd think it was a joke; but it was Java's offering for web-development, and a huge number of people CHOOSE that technology in the early 2000's.

Oops, yes I mean't JSP not JSF. I almost want to learn more about JSF, out of morbid curiosity. I'm guessing one can't bookmark any pages and the back button is broken?

> out of morbid curiosity. I'm guessing one can't bookmark any pages and the back button is broken?

Everything is broken :-)

It really should be taught in schools as how not to design anything. I actually once worked on some extension (at least I think it was) of Java Server Faces which sent serialized Java objects as hidden html-input elements (base64-encoded binary blobs) back and forth with each request(!!). At least I hope that was not part of the core JSF technology. You really should run away from most of the early Java web-tech, it truly was horrid.

It's also strange that a language, which was so "connected" to the early days of the web (even had their own html element <applet>) ended up with such strange things for web-development shortly after.

After coding some Java I understand why people hate exceptions. Suddenly the Golang authors ranting about exceptions seems somewhat rational.

I mean they still added exceptions to Golang, but are so ashamed of it they named them something else.

These people should have to code C++ for a while before being allowed to rant about exceptions.

(real C++, not Google C++ which bans exceptions for historical reasons)

But yeah, what the fuck are you doing, Java? I've yet to see a stack trace that was actually helpful.

I've worked with Java for more than a decade and I've seen plenty of stack traces that were helpful. Stack traces aren't the problem; the problem is that programmers silently swallow exceptions without either handling them or passing them up.

> Suddenly the Golang authors ranting about exceptions seems somewhat rational.

Error handling in Golang is nothing to write home about, either.

Frankly the only error handling that I haven’t actively disliked is in ML-derived languages with Either<L, R>, or Nim’s (and the latter really isn’t that far off from what we’re complaining about, but the community seems better at using it without the nested exception hell that Java and in my experience PHP can end up in)

Oh, I also like Either from Haskell. But it can get out of hand if misused by devs.

Note I say "misused" -- but it happens. After all, if Java exceptions weren't misused, there wouldn't be any problem either.

Isn't swallowing (and passing) exceptions pretty much what they are for?

Should you instead handle every error close to their source, exceptions would be an overly verbose way of doing it.

But maybe it's just my specific kind of programming prejudice shining through here.

> Isn't swallowing (and passing) exceptions pretty much what they are for?

No. You either pass them up or handle them. Silently swallowing them is a recipe for disaster, because nobody gets any info about what went wrong. In very limited cases -- e.g. "I don't care about this harmless error" -- it's correct to swallow them up, but Java devs tend to overuse it and disaster ensues.

> Should you instead handle every error close to their source [...]

You shouldn't. Handle those errors that it makes sense to handle, pass them up otherwise. Just don't swallow them.

> Should you instead handle every error close to their source

I find that this is very rarely the case. Micro-operations failing means that a MUCH higher level operation has failed.

If there's an error writing to the output file descriptor from deep within the decompression library, do you know what failed? The HTTP request. What can the decompression library, the IDS inspector, the logging system, the tracing system, or anything else do? They can just pass along the error.

Hence so much "if err != nil { return err}" in Go. The vast VAST majority of errors are not handled, they are reported.

Verbose?

benchmark b("blah"); write(http_compress(logsize(backend_decompress(out_fd, in_fd)))

It's extremely rare that something can recover from an error. And the things that can be recovered from are not exceptions in C++ (though they seem to be in Java, brrr).

Having worked on large golang code bases, I'd take Java exceptions anytime. golang error handling is not only atrocious (you end up having to manually re-invent exceptions anyway), but also error prone and dangerous.

Exceptions for deeply nested control flow drive me mental in other languages for the same reasons you’ve mentioned. Explicit Either<L, R> or similar have meant slightly more code at times, but much clearer to understand where data is going and why, in my humble opinion.

Exceptions are bad and languages using them should feel bad. Go and Rust got it right, it is a major reason why Rust code Just Works. Yet some Rust folks are moving towards exceptions, and I find it unsettling.

Exceptions are nice and languages without them should feel bad.

Your comment is a pretty useless blanket statement. At least invite some discussion by coming with a few arguments..

What is bad about exceptions?

They will be used for flow control in small, individually innocent ways until they've accumulated into the type of hell the OP of this thread is describing.

A solution is to use languages that make explicit control flow available, instead of pretending that exceptions are a good way of performing non-local jumps.

Have you investigated Common Lisp, its use of BLOCK/RETURN-FROM and TAGBODY/GO, and how it is possible to close over these lexical constructs to achieve non-local jumps to predefined points on the stack ? All of Common Lisp's error handling system is based on this primitive mechanism (and therefore written in Lisp itself).

(Disclosure: wrote a book on the topic.)

Exceptions form a secondary, unseen form of control flow. A program can exit via ‘return’ calls (as normal), or at any time by some internal function way down the stack throwing an exception for something that could have been an error code.

Exceptions are not Structured Programming: they are worse than goto, because at least goto is scope-local. If, maybe, the language enforced that all throwable exceptions are declared by the prototype, then it’d be alright. But I don’t know of any that do. So, given a function call, will it error out? Can you know without inspecting the source, if you even have it?

> they are worse than goto, because at least goto is scope-local

Thanks, you said it better than me. This is the essence.

So Go got it right by calling it panic/recover instead of throw/catch? Should we petition other languages to also change the keywords and correct whatever is wrong with throw/catch? Is Pythons raise/except safe or did they miss it when they cleaned up the master/slave mess?

Panic/recover isn't used nearly as much for error handling in Go as in Java. An online resource being unreachable does not cause the net package functions to panic.

Used or not, they ARE exceptions, and you need to write exception-safe code.

fmt.Print can throw. And HTTP handlers throwing exceptions is silently hidden. If you don't write code assuming anything can throw, then your code is broken.

And don't judge exception by how they are in Java. That's just a clusterfuck. No other language I'm aware of gets exceptions so wrong.

Panics Are exceptions but they should be seen as a fatal error. It is very discouraged from being used and the official doc insists that you should not use them for error handling. Qualifying a feature as exceptional use does count, just as having goto in C++ (and go) is possible but should be (and is) generally avoided should impact your perception of c++.

> Panics Are exceptions but they should be seen as a fatal error.

I agree. Well, "fatal" needs to be defined. If an HTTP handler throws an exception, is that fatal for the whole webserver?

Java seems crazy about this. Exceptions seems like it's being treated as just another return value. And that leads to a mess.

But C++? What parts of the C++ standard library have unreasonable exceptions used for errors? (there may be some, I just can't think of any)

And note that you have to throw (no pun intended) away large parts of the language if you remove exceptions. E.g. you can't have constructors without exceptions. How else would you signify "those arguments you gave to the constructor are no bueno".

Go doesn't have constructors, so it's consistent with what it says.

Also see my comment here, about how common or not, discouraged or not, the mere existence of exceptions in a language changes how you must write code to not have it be buggy: https://news.ycombinator.com/item?id=25275580

Yes, in C++ 'goto' is a code smell. It's not in C (greatly used for error handling), but C++ has RAII so `goto` should be rare outside of "clever" code (where "clever" is rarely good).

The mere fact that C++ doesn't have 'finally', and Java does, tells you a lot about how exceptions and RAII differs. If you write a macro for "finally" in C++ then you're doing it wrong.

Pretty much all of my `catch` clauses are in main() (or the root of an event handler), to pretty print the error and/or log to central service, or in a top level event like HTTP handler. `catch` should be about as common in C++ as `rescue` is in Go.

In Java it's fucking everywhere.

> If an HTTP handler throws an exception, is that fatal for the whole webserver?

Well, your handlers should not generally panic! It's called panic in Go so panicking should be hopefully rare for the peace of mind.

> Well, your handlers should not generally panic!

Uhm… no… no they should not.

I feel like you're missing the whole point, here. An interface that is extremely hard to use correctly without turning small bugs into major outages is not a good tool.

And one way to make sure this doesn't happen is to write exception-safe code, because Go has exceptions.

You could also argue that your C++ code shouldn't throw, and I agree. It should very rarely throw. But when it does it should be safe.

If Go had simply not had exceptions then this would have been easier.

> It's called panic in Go so panicking should be hopefully rare for the peace of mind

If you write a web service that hits a bug that panics about once per million requests, and you run 1000 qps, that means your Lock();dothing;Unlock() will deadlock the whole webserver once every 15 minutes.

If you write exception safe code, then it does not.

I was replying to the comment above -- Go or Rust did not simply rename exception related keywords, they have a completely different approach.

I don't know of any language that does mudane error handling with exceptions that is not a mess. C++, for instance, is extremely difficult to write exception safe code in.

> Go or Rust did not simply rename exception related keyword

I don't know about Rust, but Go most certainly did.

> C++, for instance, is extremely difficult to write exception safe code in.

It's WAY easier to write exception safe code in C++ than in Go, because C++ has RAII and scoped defers.

See my example for what a mess Go makes of this in this comment: https://news.ycombinator.com/item?id=25276360

I find C++ exception safe code to be pretty much trivial. Once you get used to "no naked resources" RAII just makes everything exception safe automatically.

I'd argue that Exceptions are good, because they attempt to illustrate all the ways code can go wrong and because you typically need to be at least aware that you're ignoring them.

However, i'd argue for allowing no unchecked exceptions at all that can be thrown at runtime and instead forcing developers to handle every fail state, that can be encountered in the code that they call.

If a method that you call can fail in 60 different ways, you should at least handle the 20 of them that you understand in their own ways and the rest in a blanket statement. All of that should be checked at compile-time, of course.

Java, .NET and most other ecosystems (both languages and frameworks) don't really seem to want to bother with that, though.

Is there a language that has optional checked exceptions?

Basically if I define a checked exception function then I am expected to check all exceptions that will be thrown?

In Java there is Exception (checked) and RuntimeException (unchecked). Depending on which base class you use, the compiler will force you to handle them or not.

One of the problems with exceptions is that they bubble up the call stack, and then you've got layering violations: higher level modules should never depend on lower level modules. The "checked exceptions were a failure" meme goes towards this direction, it results either in nasty boilerplate because you've got to handle and re-wrap the implementation-specific exception in something more general to avoid leaking things that should have been hidden (like Hibernate does), or unsound error handling.

Maybe the solution to that is

1. Only allow checked exceptions, and force error handling.

2. Only have 2-3 exception types, not user-extendable: Retryable, Unrecoverable, and Error (for non-user code errors like OOM). OTOH, how to distinguish between different exceptions thrown by the same method, and how to add additional error information (like status_code) would become a problem. Javascript doesn't seem to care tho?

A Result type à la Rust solves most of that: you might still have to wrap lower layers, but at least the noise & syntax is much more sane (never thought I'd say that about Rust!).

JavaScripts Error type is so loosey-goosey that even TypeScript doesn’t try to work anything out about it. e: any; parse it yourself in your catch haha

Go has exceptions, though.

Unwind stack, calling cleanup functions in frames that need them, until caught higher up the stacks. Yah, that's exceptions.

This is insincere. Rust can unwind too, but as in Go, this not the usual error handling mechanism.

I haven't learned Rust yet, but no it's not insincere. Go has a textbook definition of exceptions.

The mere fact that they are less used doesn't make them "not exceptions".

And importantly it doesn't matter that they are less common. Merely having exceptions means that everyone has to write exception-safe code.

HTTP handlers silently swallow exceptions, so you can't rely on your program dying if there's a panic.

fmt.Printf can panic as far as you know, too.

Essentially you need RAII, except that because Go doesn't have RAII every single resource needs:

r, err := getResource() if err != nil { … } defer r.Close()

But because "Go doesn't have exceptions" people often don't bother with the defer, and then they get bugs. I see it happening frequently.

You need to write exception-safe code. But also you're not allowed to use exceptions. So it's the worst of both worlds.

I write and review a lot of Go code, and I like the language. But I don't like the dishonesty.

> You need to write exception-safe code. But also you're not allowed to use exceptions. So it's the worst of both worlds.

I wasn't aware that this is a real problem in Go land, thanks for the explanation. I wouldn't say the language is "great", was just using it as an example of a modern language where there is a consensus that "they got it right" and not using exceptions, even though error handling is still tedious right now.

I think in Rust you have to consciously fuck up the panic handler to cause similar issues, but I'm not sure.

What's the equivalent in rust of defer? E.g. this code in Go is buggy:

mu.Lock(); fmt.Print(someoneElsesObject);mu.Unlock();return

You need to get into the habit of writing:

mu.Lock(); defer mu.Unlock(); fmt.Print(someoneElsesObject);return

And this gets extra complicated by the fact that in Go defer runs at end of function, not end of scope. This makes every single for-loop that needs to lock anything hard to read and annoying to write.

for _, a := range stuff { if err:=func()error { mu.Lock();defer mu.Unlock(); return a.stuff()}(); err != nil {return err}}

You use RAII, to put it in C++ terms. To use your variable names, someoneElsesObject is inside mu, and is returned by mu.lock. When it goes out of scope, it will unlock.

You can also use defer if you want, but I've never seen it in real code, it's more error-prone and not as flexible. You can build it on top of RAII.

I'm not following what you're saying.

I'm saying "mu.Unlock()" except when deferred, is essentially always a bug. At the very least it's a bug waiting to happen. You need to prove that everything between Lock and Unlock is exception-safe. And that's rarely possible.

As I've said elsewhere you cannot rely on panic triggering program exit, since e.g. HTTP handlers swallow panics.

The fact that you seem to be saying you never see an Unlock deferred proves my point that saying "Go doesn't have exceptions" hurts Go programming. And Go code is in fact full of bugs because there's all this exception-unsafe code.

C++ is naturally exception safe, because RAII. Where it's not exception safe it's because RAII was not used.

Even something as simple as:

mu.Lock()

stats[metricName]++

mu.Unlock()

will throw if there's a path where stats[] map was not inited, and if called in an HTTP handler will leave the lock in place, leading to probably a deadlock of the server. Not great.

The Rust code would be, roughly (I tried to keep names similar even though Rust would use a slightly different naming scheme)

  let someoneElsesObject = mu.lock();
  println!("{}", someoneElsesObject);
  return;

when someoneElsesObject goes out of scope, the mutex is unlocked. This happens no matter how it goes out of scope. You cannot forget to do it, because the only way to get access to someoneElsesObject in the first place is locking the mutex, because mutexes wrap the data that they are protecting.

https://crates.io/crates/defer exists, but it would be weird to try and use it here, because it can't really be combined directly with this. I guess in theory you could put drop(someoneElsesObject) in the defer block, but like... that already happens for free.

Ah, that looks neat. Among my huge backlog project list, learning Rust is on there.

Yeah looks more RAII, and looks like it would not have the problem Go has.

Thanks.

In go, you can just inline a lambda to force defer to adhere to any scope that you the programmer decide upon.

func(){

Code for lock and deferred unlock here

}()

Well, no you can't, because that leaves no way to directly return from the function.

Hence my example where the lambda has to return an error, and the loop has to check for the error. It's A LOT of boilerplate.

Edit: Actually now I don't know what you mean. You clearly replied to my comment that gave a clear example with a return from within the lambda, so what did you think that I didn't know? You took my example and removed extremely commonly needed functionality. So… huh?

There are times that exceptions work really well, I think the problem isn't so much that they exist, as they're too often used wrong. Getting an exception due to a real error is nice, getting them as a generic flow control device, not so much.

golang definitely did not get it right. golang errors are error prone, I've seen several cases in production code where they were either accidentally ignored or overwritten. Makes it terrible for writing safe software.

Reply on news.ycombinator.com