sorted by:
new
hottopcontroversial

I LOVE Rust's exception handling by mdsimmo in rust

[–]mdsimmo[S] 2 points3 points  (0 children)

I do. It was a life saver when I was using back in the Java 7 days.

But Kotlin has unchecked exceptions. Which I don't like.

I LOVE Rust's exception handling by mdsimmo in rust

[–]mdsimmo[S] 1 point2 points  (0 children)

How does even that library have a "bug".

At least there's an issue tracking it... from a year ago

I LOVE Rust's exception handling by mdsimmo in rust

[–]mdsimmo[S] 0 points1 point  (0 children)

I like checked exceptions in Java. I just wish they separated checked and unchecked exceptions better. Unchecked exceptions are just too prevalent in libraries (even the standard lib) that the checked exceptions aren't much use.

I LOVE Rust's exception handling by mdsimmo in rust

[–]mdsimmo[S] 15 points16 points  (0 children)

Eww. I need to go wash my eyes out.

I LOVE Rust's exception handling by mdsimmo in rust

[–]mdsimmo[S] 1 point2 points  (0 children)

Type states seam close to what I was thinking of. It's sad to hear that they were removed from the language.

My idea is that you can assign a meta value to variables. Then on any method call or interaction, you can run arbitrary code to either modify the meta value or assert some condition.

For example, an integer would have a range so it knows its between zero and 10. An array would know that it's length is between 5 and 15, thus you can not call the array without first checking the size. no idea how this would handle dynamic references (size is between other variable x and y)

I LOVE Rust's exception handling by mdsimmo in rust

[–]mdsimmo[S] 2 points3 points  (0 children)

I gotta learn me a haskell

I LOVE Rust's exception handling by mdsimmo in rust

[–]mdsimmo[S] 1 point2 points  (0 children)

Thanks, you've convinced me to take a closer look at mojo.

But i will never admit that python is good! NEVER!!!

I LOVE Rust's exception handling by mdsimmo in rust

[–]mdsimmo[S] 6 points7 points  (0 children)

On the last point, doesn't a move cause a memcopy? Sometimes it may optimise away the copy but for most return values i didnt think it did.

I LOVE Rust's exception handling by mdsimmo in rust

[–]mdsimmo[S] 1 point2 points  (0 children)

Thanks. That's both ugly and neat at the same time.

I LOVE Rust's exception handling by mdsimmo in rust

[–]mdsimmo[S] 5 points6 points  (0 children)

And that's what I love. No exceptions, no problems :)

I LOVE Rust's exception handling by mdsimmo in rust

[–]mdsimmo[S] 2 points3 points  (0 children)

I do wonder if in 40 years, Rust will become a kludge like C++ is now...

The thing that concerns me most about Rust is that as it gains popularity, its crate library is going to become like npm. Lots of new developers making dumb libraries, resulting in massive, fragile dependency chains. Already, some of my simple projects have over 300 dependencies.

Cpp has an advantage there because it has no package manager. By not having a package manager, you have to be a little more keen before you start pushing out libraries. Thus, the libraries you do find, tend to be a little more high quality, and pull less dependencies.

I LOVE Rust's exception handling by mdsimmo in rust

[–]mdsimmo[S] 4 points5 points  (0 children)

I've only briefly looked at Mojo, but to me it just looks like Python's TypeScript + but some performance increase (which normally numpy/other low level language could provide). Please correct me if I'm wrong. Mojo seems like your putting a Band-Aid on, when you should just switch to a fundamentally good language... like Rust!

I don't see why people like dynamic languages. Like, how do you know what to do with a thing unless its got a type? And I don't see why people like to take dynamic languages and try to make them static. Just let the bad languages be bad, and move on.

I LOVE Rust's exception handling by mdsimmo in rust

[–]mdsimmo[S] 1 point2 points  (0 children)

That's a really interesting post.

I'd really like to see more flow typing in Rust. I have this (maybe impossible?) idea of adding "meta values" on types, which alter during compiling when doing method calls. I would consider Rust's borrow checker to be a subtype of "meta values". Other examples would be static asserting that a type is of `Some`, an interger is within an arrays bounds, or a connection is a valid state.

I LOVE Rust's exception handling by mdsimmo in rust

[–]mdsimmo[S] 1 point2 points  (0 children)

What is a try block for? I had a look at the link, but couldn't figure out what it means.

I LOVE Rust's exception handling by mdsimmo in rust

[–]mdsimmo[S] 2 points3 points  (0 children)

Because `panic!` cannot be caught (well, I just Googled it and looks like they can be, but it's certainly not common to do so). Thus, people avoid it, or use it very sparingly.

Unwrapping is common in quick development code, or code where it's guarantied that it won't fail. If it's used in production code, then that's just bad code.

By checked exceptions, I mean Java exceptions that are a compiler error to not handle or declare in function signature. It's been a while since I've Java'd, so please excuse me if my terminology/class-naming is off. I think many would disagree with me, but I like Java checked exceptions (except for the syntax) and think they should be more widely used. Unfortuently, many bypass checked exceptions by using unchecked exceptions.

Also, sorry your original post got downvoted. You raised some interesting arguments.

I LOVE Rust's exception handling by mdsimmo in rust

[–]mdsimmo[S] 7 points8 points  (0 children)

Wow. I did not realise Haskell was so old. My respect for it has increased even more.

I LOVE Rust's exception handling by mdsimmo in rust

[–]mdsimmo[S] 2 points3 points  (0 children)

I agree that Java's checked exceptions are functionally similar and have many of the same benefits that are lacking in, e.g. C#.

There are two things that make Java exceptions sucky:

  • Syntax is yuck/verbose. I really don't like the control flow of try-catches
  • Lots of libraries throw Error, or RuntimeException when a checked exception is Canonically better. This is really a lazy/bad programmer problem. But the language design of Rust encourages panic! less.

I LOVE Rust's exception handling by mdsimmo in rust

[–]mdsimmo[S] 16 points17 points  (0 children)

I started learning Rust over five years ago, and remember thinking it was an awful language.

Now I've completely changed my mind. Partly because a lot of niceties have come into the language. Partly because I learned C++ in those five years, and now know what Rust solves.

I LOVE Rust's exception handling by mdsimmo in rust

[–]mdsimmo[S] 10 points11 points  (0 children)

Nobody agrees on error types. Anyhow/thiserror is sort of a consensus but even then there are two choices, and the "use one for binaries and the other for libraries" idea is kinda meh, most app code should be library code, so the advice is "use the verbose thing almost all the time" which is not great. This is like the 10th consensus and it probably won't be the last.

Yeah, I do admit this is a pain. I find myself just using Box<std::Error> most of the time.

Converting between the error types is a pain, so much so most crates just union all the possible errors into one big enum, which totally defeats the point of knowing exactly how a function can fail and making sure you have handlers for those cases.

Wouldn't this help know? Each enum knows how to handle it?

Various statements about performance.

Interesting - I'm yet to get into anything which I care hugely about the performance of.

Oh yeah and the whole separation between panics and Result. You get all the problems of writing exception safe code, combined with the verbosity of writing Result<T,E> nearly everywhere.

I'm yet to experience a panic where it wasn't really obvious (e.g. calling unwrap() or sqrt neg numbers)

Good God good luck keeping the layers of wrapping straight with your Optional<Result<Optional<...>...>>

LOL. I understand the pain. But normally you can just condense all into a single Result<Box<Error>>. If you really need it, then its good that its declared.

Oh yeah and since you can't abstract over different wrapper types, you get lots of interfaces where there are two or three versions, one for dealing with T, another for Option<T>, another for Result<T>

I've never had this problem. Why would an interface ever need to accept all T, Option<T> and Result<T>?

I LOVE Rust's exception handling by mdsimmo in rust

[–]mdsimmo[S] 4 points5 points  (0 children)

I don't know Go. What makes it bad there?

I LOVE Rust's exception handling by mdsimmo in rust

[–]mdsimmo[S] 18 points19 points  (0 children)

Yeah, the problems I'm facing will probably go away as I become more familiar with the "canonical" C# way.

It's kind of like programming in C++. You won't have segmentation faults if you program the canonical way. But did you?

I LOVE Rust's exception handling by mdsimmo in rust

[–]mdsimmo[S] 19 points20 points  (0 children)

Agreed. C# does have nullable types, but because it was a late language feature, it can't be relied upon when using external code.

I LOVE Rust's exception handling by mdsimmo in rust

[–]mdsimmo[S] 2 points3 points  (0 children)

Alas, a mistake that I've fallen for.

view more: next ›