Unwrap Error Shorthand?

[pliant mist]

Was wondering if there was a shorthand for catch unreachable for ignoring possible errors (similar to .? for optionals)

[edgy crane]

there is not, they explicitly decided against adding .! iirc

[pliant mist]

hmm

well that kind sucks

lol

alright ill just stick with a catch

[spare knot]

One thing is that catch unreachable only ignores errors in production builds, it also conveys the concept that the error cannot happen not that you you want to ignore it. If you want to really fully ignore them in all situations you should use catch {} which both always ignores and conveys that you do not care about the error.

[edgy crane]

yea keep in mind that .? and catch unreachable are a panic with safety checking

[pliant mist]

oh

alright thats a lot shorter ill use that

i do have some spots in my code that unreachable makes more sense too so ill leave that

[pliant mist]

yea in the instances im placing it i just want to crash if the error occurs

[pliant mist]

hm okay, will this work in all instances? im trying to return the result of an allocation and doing catch {} says its returning void instead of []u8

[edgy crane]

better to do catch @panic() then

[pliant mist]

kk

[edgy crane]

catch unreachable is assert that the error will never occur

maybe you get it already just wanted to make sure

[pliant mist]

yea that makes sense

[spare knot]

If you really do not care about the error and the function is not void you need to provide a fallback of the same time you can also do catch return in some cases where you only want to early exit that one function

But like @edgy crane said you probably want panic

[pliant mist]

well most of these are going to be for allocations

or things that cant happen like non exhaustive switch cases that the compiler cant see are impossible

so for the switch cases ill do unreachable and allocations ill do panics

[spare knot]

try is like panic but let's you catch higher up the call stack which is often nicer as something to considered

[edgy crane]

even in a simple application its sometimes helpful to just bubble the OOM up to main

[pliant mist]

that would require putting errors in all of the return values no?

[edgy crane]

instead of dying immediately

[pliant mist]

or is it like exceptions

[edgy crane]

yes

which is desirable, because it shows which parts of the code are doing allocation and could fail with out of memory

[spare knot]

Adding that a function could error is just one extra character per signature plus try when calling

[pliant mist]

hmm, i thought i would need to specify the error return type

is the default just some catch all generic error?

[spare knot]

`!void' is the syntax

[pliant mist]

yea, i thought the error type went on the left

ive seen it in some of the docs

[spare knot]

Or ! Whatever type the left is optional

[edgy crane]

!T creates an implicit error set that is all of the errors that the function could return with

[pliant mist]

oh

🤔

[spare knot]

The left is nice to make explicit some of the time but not necessary unless you are using function pointers

[edgy crane]

so if you add a try or return error.Blah it automatically adds it

[pliant mist]

thats nice okay

ill probably do that then

[edgy crane]

if im making a function that just fails with OOM i usually make it Allocator.Error!void etc

[pliant mist]

but just !void works right?

i dont actually care about catching any of these errors tbh

they should be unrecoverable

[edgy crane]

yes, but if u want to be disciplined its better to define actual error sets

[pliant mist]

right

[edgy crane]

but for just quick prototyping etc its not horrible

[pliant mist]

alright thanks for the help, ill play around with it