01:58 <FromGitter> <jrei:matrix.org> In Swift, there a `throws` keyword in the function declaration to indicate that it can throw an error. ⏎ By the way they are similar to returns, they don't involve stack unwinding

02:04 <FromGitter> <jrei:matrix.org> So it forces the user to catch the error inside functions that don't have the `throws` keyword. ⏎ However, I'm not sure it solves the "knowing all possible errors" issue, catch all errors still exist

02:37 <FromGitter> <moe:busyloop.net> i haven't used swift but that sounds like checked exceptions.

02:39 <FromGitter> <moe:busyloop.net> i don't want to litter all methods with `throws`, that gets old quick. ⏎ i only want to put it on chosen methods where i care. "the buck stops here".

02:41 <FromGitter> <moe:busyloop.net> shard developers would be advised to put `throws` on all their public methods. ⏎ but even if they don't, i can still put it on my method that calls them and get a nice list of all the exceptions ⏎ they either deliberately expose - or forgot to handle (e.g. if i see a sth like `IndexError` i'll file a github ticket - but at ⏎ least i'll know it's there and i can handle it for the time being)

02:41 <FromGitter> ... [https://gitter.im/crystal-lang/crystal?at=63705944f9491f62c9af7d9c]

02:42 <FromGitter> <moe:busyloop.net> as a bonus it would also be nicely backwards compatible. ⏎ your code will still compile even if it doesn't contain a single `throws` :)

02:49 <FromGitter> <moe:busyloop.net> would also match the crystal philosophy well i think. "exception inference" just like we have type inference. ⏎ allows me to be strict where i need to be and otherwise stays out of my way.

10:38 <FromGitter> <jrei:matrix.org> It is not that different from methods that can return nil, with adding `nil` to the return type union. ⏎ In Crystal it could be like, say `String | Error`, or `String!`, compared to `String | Nil` and `String?`.

10:39 <FromGitter> <jrei:matrix.org> But yes if this is to add to all methods, it is pointless

10:40 <FromGitter> <jrei:matrix.org> Or maybe another return field, separated to the existing one for return values

10:41 <FromGitter> <jrei:matrix.org> I don't find much a difference between inferring return types and exceptions at the end

11:25 <FromGitter> <moe:busyloop.net> hm yea, syntax-wise i think i'd keep it separate from return-types. ⏎ e.g.: ⏎ `def user(id : String) : User? throws DatabaseTimeoutError | SqlError` ⏎ ⏎ i.e. i don't want to allow that method to `return` SqlError, it's only allowed to `raise` it. ... [https://gitter.im/crystal-lang/crystal?at=6370d43715a3885c70ec2552]

11:29 <FromGitter> <moe:busyloop.net> would def also need a way to declare that a method is not allowed to throw anything. ⏎ perhaps just `throws Nil` or a magic keyword like `throws nothing`. ⏎ ⏎ (i'm not married to any specifics or the word "throws" anyway - maybe calling it `raises` would be clearer) [https://gitter.im/crystal-lang/crystal?at=6370d5222cb6570240262b33]

11:34 <FromGitter> <moe:busyloop.net> ideally, when the constraint is violated, the compiler would even tell me which line violates it; ⏎ `Line 123 in user.cr: db#query may raise IndexError but #user is only allowed to raise DatabaseTimeoutError | SqlError`

11:35 <FromGitter> <moe:busyloop.net> (but i understand i'm asking a lot here 😅)

11:35 <FromGitter> <jrei:matrix.org> Agreed, and would be one step to more safety

11:42 <FromGitter> <moe:busyloop.net> yup, i also agree with the comparison to return-types. ⏎ in practice exceptions are additional return types (outcomes) of a method. ⏎ currently we just have no way to restrict them like we have for return-types - not even one to easily find out ⏎ which of them may bubble up from the depths of the callstack. [https://gitter.im/crystal-lang/crystal?at=6370d82fb1a75964366d3b7d]

11:44 <FromGitter> <HertzDevil> syntax-wise there is already `@[Raises]`

11:47 <FromGitter> <HertzDevil> c++ used to have this too but it didn't actually prevent functions during compile-time from raising exceptions not declared

11:48 <FromGitter> <moe:busyloop.net> hm yea, but i feel like if we allow to actually restrict them then a syntax like `throws` would be nicer. ⏎ (annotation would be less readable imho - but hey if that gets me the feature, i won't complain)

11:51 <FromGitter> <moe:busyloop.net> i don't know of any language that actually has this exact feature (they may exist but i don't know one). ⏎ maybe it's really hard to implement, i have no idea. ⏎ or there is some logical problem with it that i'm not seeing. ⏎ so far, in my mind, it would be tremendously useful to make my code safer. [https://gitter.im/crystal-lang/crystal?at=6370da3f25ca105c88b43a23]

11:51 <FromGitter> <HertzDevil> all that's left in c++ is `noexcept` which still isn't a compile-time check, it merely calls `std::terminate` whenever something throws

11:55 <FromGitter> <moe:busyloop.net> so basically just a `rescue exit(1)`? 🤔

11:59 <FromGitter> <moe:busyloop.net> i've used a crystal shard that did pretty much that: https://github.com/arcage/crystal-email/issues/56 ⏎ it was not great, to say the least...

13:41 <FromGitter> <HertzDevil> more accurately it raises `SIGABRT` and does not run `at_exit` stuffs

13:43 <FromGitter> <HertzDevil> back to crystal, the moment we do this, then either every `@[Raises]` will be littered with `ArgumentError | OverflowError | IndexError | NilAssertionError`, or we have to define checked vs unchecked exceptions

13:52 <FromGitter> <moe:busyloop.net> hm, not sure i would call that littered. if that's what a method can raise then it should be in the docs, right?

13:54 <FromGitter> <moe:busyloop.net> and people wouldn't have to declare them manually. ⏎ they would just start noticing them when i declare something like `throws MyCustomException` higher up the chain ⏎ and then see "oh, an OverflowError can also bubble up to here? i should handle that either here, or where it originates"

13:56 <FromGitter> <moe:busyloop.net> or in other words: all exceptions remain unchecked by default. you just get syntax to check them in places where you want to.

13:59 <FromGitter> <moe:busyloop.net> in many cases the actual handling of these will likely still look the same as it does today: with a catch-all `rescue` in the method ⏎ where e.g. `OverflowError` can happen. the new syntax would make it easier to not forget about doing that (which as of today probably happens a lot more often than anyone likes to admit ;))

14:09 <FromGitter> <moe:busyloop.net> to try another example: ⏎ when i use a shard then i'd expect that shard to not throw random IndexError or OverflowErrors at me. ⏎ so shard authors would be encouraged to narrow all their public methods to only `throw WellDefinedErrorA, WellDefinedErrorB`. ⏎ ⏎ but what happens below these public methods remains up to them. ... [https://gitter.im/crystal-

14:09 <FromGitter> ... lang/crystal?at=6370fa7eff5546644b425e90]

14:57 <FromGitter> <HertzDevil> that only gives a false sense of security because without "checked" exceptions library writers *will* do the `rescue exit(1)` thing just to satisfy the `@[Raises]` contract

14:59 <FromGitter> <HertzDevil> and crystal developers would simply not use them at this rate, because this doesn't promote their happiness

15:01 <FromGitter> <HertzDevil> a `@[Raises(NoReturn)]` would be interesting because that's the one that has considerable codegen impact, but the issue is the same: people will do `rescue exit(1)` again, unless they're working with the empty prelude

15:02 <FromGitter> <moe:busyloop.net> seems unlikely to me. ⏎ developers who don't care wouldn't put in the contracts to begin with, so there are no `rescue exit` to write for them. ⏎ ⏎ and i think there are quite a few crystal developers (and even more *potential* crystal developers) ⏎ who do care a lot about runtime safety and would draw happiness from being able to ensure it. [https://gitt

15:02 <FromGitter> ... er.im/crystal-lang/crystal?at=63710716473cf96648e3d16f]

15:04 <FromGitter> <moe:busyloop.net> seeing production apps crash from random `IndexError` or `OverflowError` definitely does not help happiness. ⏎ especially not when paired with the often useless backtraces (`???`). i've had some rather unpleasant conversation about ⏎ this in my org where i'm trying to promote crystal for production use.

15:06 <FromGitter> <moe:busyloop.net> (to be precise, i've had multiple occasions where production would crash with `IndexError`, following by a bunch of `???` without any filenames or line numbers. that's the digital equivalent of a middle finger...)

15:07 <FromGitter> <Blacksmoke16> i still think you should handle that by having a fallback that handles unexpected exceptions...

15:07 <FromGitter> <Blacksmoke16> but the `???` is prob because it was built with `--no-debug` and/or stripped

15:07 <FromGitter> <Blacksmoke16> afaik all that does is reduce binary size, so if thats not a big deal, prob could just keep debug symbols so you have them for when this happens

15:08 <FromGitter> <moe:busyloop.net> it was build with `--release --static` and not stripped.

15:08 <FromGitter> <Blacksmoke16> could maybe try adding an explicit `--debug` then?

15:09 <FromGitter> <moe:busyloop.net> i don't remember what i did back then (probably built without --release). ⏎ but this is a separate subject (although it also relates to production readyness)

15:11 <FromGitter> <moe:busyloop.net> > i still think you should handle that by having a fallback that handles unexpected exceptions... ⏎ ⏎ yes, that's what i do (and presumably everyone does). ⏎ doesn't change the fact that a missed `IndexError` will cause an error or even crash in production. ⏎ ... [https://gitter.im/crystal-lang/crystal?at=63710927a34b5112112c118f]

15:12 <FromGitter> <Blacksmoke16> yea for sure, but i also agree with hertzdevil in that it feels a bit annoying needing to do `throws IndexError` just because i do like `arr[0]`

15:12 <FromGitter> <Blacksmoke16> even in casese where i can know i wont raise

15:13 <FromGitter> <Blacksmoke16> kinda like that new ameba rule...not sure warning on `.not_nil!` provides any benefit...

15:14 <FromGitter> <Blacksmoke16> same idea with math, anytime you do `a + b`, do you need to mark that as being able to overlofw/

15:14 <FromGitter> <naqvis> > kinda like that new ameba rule...not sure warning on `.not_nil!` provides any benefit... ⏎ ⏎ that's really annoying and big pita imo. Without knowing the context, linter just throwing warnings as a general concept, isn't something good

15:15 <FromGitter> <moe:busyloop.net> as described above, you would pretty much never actually declare `throws IndexError`. ⏎ either you don't care in this method, then you simply don't declare a `throws` at all. ⏎ ⏎ or you do care, in which case you will handle it but most likely not let it bubble further. [https://gitter.im/crystal-lang/crystal?at=637109f715a3885c70ec84b6]

15:15 <FromGitter> <Blacksmoke16> ah gotcha 👍

15:15 <FromGitter> <Blacksmoke16> i didnt read all of it 😅 🙈

15:16 <FromGitter> <Blacksmoke16> @naqvis https://github.com/athena-framework/athena/actions/runs/3398343461/jobs/5651304890

15:16 <FromGitter> <moe:busyloop.net> yea, that's the main difference between my proposal and the common "checked exceptions". ⏎ it's purely opt-in, so existing crystal code would not have to change at all.

15:16 <FromGitter> <Blacksmoke16> so pretty much yea, just says: ⏎ ⏎ > Avoid using `not_nil!`

15:17 <FromGitter> <naqvis> > @naqvis https://github.com/athena-framework/athena/actions/runs/3398343461/jobs/5651304890 ⏎ ⏎ 😃 , so i had it just disabled

15:17 <FromGitter> <moe:busyloop.net> that warning is indeed silly. there are plenty cases where you just can't avoid using it. that's why it's in the language, duh.

15:37 <FromGitter> <Blacksmoke16> i replied to the PR, worst case ill just disable it i guss

16:35 <FromGitter> <HertzDevil> > as described above, you would pretty much never actually declare `throws IndexError`. ⏎ > either you don't care in this method, then you simply don't declare a `throws` at all. ⏎ > ⏎ > or you do care, in which case you will handle it but most likely not let it bubble further. ⏎ ... [https://gitter.im/crystal-lang/crystal?at=63711cd725ca105c88b4a6d8]

16:40 <FromGitter> <HertzDevil> unless some exceptions are made "unchecked" in java's sense

16:41 <FromGitter> <HertzDevil> which will of course weaken every `@[Raises]` contract

17:40 <FromGitter> <moe:busyloop.net> well, in practice in the places where you put a `throws` you *do* care about all exceptions that can be raised. that's the whole point.

17:42 <FromGitter> <moe:busyloop.net> e.g. if i build a shard that exposes a `def send_email` then i'll want to make that `def send_email throws SendError`, so my caller knows what to expect. any other spurious `IndexError` and such i would obv handle and not throw at them.

17:45 <FromGitter> <moe:busyloop.net> but most method could still go without a `throws` and behave just like today. ⏎ it's just about narrowing down the stream of possible exceptions in strategic places. ⏎ because letting an `IndexError` bubble all the way to the top-level is usually a bug waiting to happen anyway.