4 ms·
There are cases where you might want to choose: crash and burn, or handle at runtime. Where this makes sense, Inko does actually let you do that. For example, a
by YorickPeterse 2y ago
There are cases where you might want to choose: crash and burn, or handle at runtime. Where this makes sense, Inko does actually let you do that. For example, array indexing is done using one of two methods:
- Array.get/Array.get_mut for when you want to panic on an out-of-bounds index
- Array.opt/Array.opt_mut for when you want an Option type, with it being a None for an out of bounds index
So for example:
[10, 20, 30].get(0) => 10
[10, 20, 30].get(42) => panic
[10, 20, 30].opt(0) => Option.Some(10)
[10, 20, 30].opt(42) => Option.None
This pattern is applied across the standard library where this makes sense, such that the developer can pick which option works best for their needs.
There are a few places where we check for some input at runtime and panic if this is invalid, but this is limited to cases where there's simply no sensible alternative (e.g. providing a key with an invalid size to a ChaCha20 cipher).
- dullcrisp 2y agoIf panics can’t be handled at runtime they need to be impossible to introduce. Saying they just need to be fixed immediately might make sense for a project with a handful of developers but as others have said a major production system failing due to a panic wouldn’t be acceptable.
- Too 2y agoWith those two names it's rather inevitable that any beginner of the language will use the obvious sounding, but panic-inducing get. That's not scalable if it's not possible to catch panics. If panics can't be handled they must only be caused by super corner 0.001% cases, not by fundamental things like dividing an integer or indexing an array.
- Muximize 2y agoI think this is bad api design. The opt method should not exist, and the get method should return option.