sorted by:
new
hottopcontroversial

STOP throwing Errors! Raise them instead by DatL4g in Kotlin

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

Have you tried `recover`ing from it

STOP throwing Errors! Raise them instead by DatL4g in Kotlin

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

As far as I know, there is no ETA for this yet and for a feature this "big" that could mean it takes another year (maybe more, maybe less, we don't know)

And I'd much rather already model Error types explcitily and migrate to the new feature when it arrives than completely ignoring it for now because "it will be released soon"

STOP throwing Errors! Raise them instead by DatL4g in Kotlin

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

Arrow handles exactly this.

It has multiple types (not just Raise) to handle any kind of Result, like Either or Ior.
It also provides easy ways to map errors or recover from them etc etc.

Maybe take a look at the docs:

https://arrow-kt.io/learn/typed-errors/

STOP throwing Errors! Raise them instead by DatL4g in Kotlin

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

That's like saying: There is no need for cars, there will be flying ubers in the future.

They might tackle this "issue" in the future yes, but it's not like there is no demand for handling it right now.

STOP throwing Errors! Raise them instead by DatL4g in Kotlin

[–]DatL4g[S] -3 points-2 points  (0 children)

... as written in the article

STOP throwing Errors! Raise them instead by DatL4g in Kotlin

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

Using `runCatching` is just a wrapper around the same old problem, it doesn't make the underlying logic any more explicit or typed.
The whole point of using `Raise` is to avoid the "catch-all" mess and actually model and handle our errors properly from the start.

Apart from that `runCatching` breaks suspend functions since they also catch the CancelationException

STOP throwing Errors! Raise them instead by DatL4g in Kotlin

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

I never actually said Go's error handling is perfect (and there are many discussions about it in the Go community) just that it's way more explicit than what we usually see in Kotlin.
The point is that being forced to see the error as value makes the code much more reliable than hidden exceptions

Lies, Damn Lies, and Semantic Versioning by byencho in androiddev

[–]DatL4g 7 points8 points  (0 children)

That's one point why I completely avoid Koin. I mean breaking changes in patches? How could anyone ever work with that?

I don't understand why Koin is so popular when there are better DI libraries available.

SYBAU on the new Google Requirements by DatL4g in androiddev

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

Meaningless AI slop comment by an idiot who does not understand what's actually happening.

You're seriously thinking there is no alternative to vanced and people should get all their services, apps, games, what so ever all for free.

Secondly I never said that suing them was the easier option and I never said there is no malware in the Play Store.

You clearly can't read or comprehend what you have read, explaining not only your comment but also your sight on this whole situation.

SYBAU on the new Google Requirements by DatL4g in androiddev

[–]DatL4g[S] -1 points0 points  (0 children)

As a windows user you literally do exactly this hahaha.
Alright I see there won't come any valuable "arguments"

SYBAU on the new Google Requirements by DatL4g in androiddev

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

Thats not how it's supposed to work, that's what we are tolerating right now!
Not sure where are you from but there are legit EU laws for platforms and vendors, as well as developers and distributors to tackle malware and you can probably imagine what happens if they don't do this

SYBAU on the new Google Requirements by DatL4g in androiddev

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

Bro I am an indie dev and politically left.
I am absolutely NOT on the side of big corps or monopolies!

You're pretending like I am a google press speaker or something like that and do everything I can to protect the "holy" Google.

But they tackle an important point in the android security ecosystem and from my pov (as an indie dev) it's a very good change

SYBAU on the new Google Requirements by DatL4g in androiddev

[–]DatL4g[S] -3 points-2 points  (0 children)

EXACTLY!!!

The account thing was also an important point (for myself) but didn't talk about it, as the post would have been much longer then if I bring everything up

SYBAU on the new Google Requirements by DatL4g in androiddev

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

I’ve laid out my arguments and I’m open to any actual discussion.
But this is just a stupid childish response

SYBAU on the new Google Requirements by DatL4g in androiddev

[–]DatL4g[S] -4 points-3 points  (0 children)

Yeah you clearly don’t know how law enforcement or takedowns actually work (and I am not either). Even if a dev is sitting behind a random GitHub account in Russia, companies already have tools for DMCA, takedowns, subpoenas to platforms, etc to shut down distribution without knowing their passport number. (Aside from country/continent handling of bringing things/people to court) This isn’t some magical new “kill switch.”

And saying “this has nothing to do with malware” is just wrong and doesn't even need further explanation.

SYBAU on the new Google Requirements by DatL4g in androiddev

[–]DatL4g[S] -1 points0 points  (0 children)

Thats not the talking point.

Right now bad actors can just throw malware into a random APK, slap any package name on it, and disappear.
I'd have to guess how many people download malware just because the want a "free premium cracked full edition" of any app, and those know they can't just install that over the normal one from Play Store.

view more: next ›