7 ms·
index out of bounds errors are handled in separate ways depending on the kind of array you are using. If I understand how it works correctly, you can be working
by b0b_d0e 12y ago
index out of bounds errors are handled in separate ways depending on the kind of array you are using. If I understand how it works correctly, you can be working with one of three main kinds of arrays: slices with a known length, slices with an unknown length, or a growable vector. In the case of slices with a known length, ie: let a = [0]; then trying to say a[1] is a compile error since the compiler knows the length of the array at compile time, it will not let this code compile. In the case of an unknown length at compile time, the compiler cannot really help you here, but it will cause a task failure when you try to access out of bounds (since it does know the length at runtime, it checks to make sure that it is in bounds). This is similar to what happens when you are trying to access an element that doesn't exist on growable vector as well. I hope this information clears up somethings for you and even more so I hope my information is correct! I'm still learning rust, so I still have misunderstandings quite often.
- sisalcat 12y ago> it will cause a task failure i.e. a crash.
- dbaupp 12y agoIt doesn't necessarily take down the whole program, ice. it's recoverable, unlike memory corruption or a segfault. (Yes I know you can install signal handlers for segv, but that is not isolated at a language level like a task failure is with Rust.)
- sisalcat 12y agoYes, I can catch SIGSEGV. And I can catch Java NullPointerExceptions and ArrayIndexOutOfBoundsExceptions. So Java prevents all crashes, lol.
- dbaupp 12y agoYes, Java applications are rarely killed by the OS/memory manager for trying to access memory they don't have control over.
- sisalcat 12y agoThat's a strange definition of "crash" you have there. I should go tell my customers next time that their programs definitely didn't crash.
- alkonaut 12y agoJava raises an exception. If you handle it in code, the app does not crash. The crash is a consequence of failure to handle and recover from the exception. Granted, it is very rare that you can/should recover from nullpointer or OOB exceptions anyway. What you can do though is try to clean up things, show a polite message and shut down the application in a semi-controlled way. "Preventing crashes" isn't the best description of Rust's novel protection systems. In my opinion, the best part is providing guarantees about data integrity and security, e.g. preventing heartbleed type read-overruns and preventing data races in concurrent code due to shared mutable state.
- AlisdairO 12y agoIt's not that uncommon to want to recover from NPEs in a webapp environment. You want your thread of execution to error out, return a 500, and rollback whatever db changes it's made, but you want the webapp as a whole to keep running.
- lucian1900 12y agoAnd this is precisely what task failure in Rust lets you do. Requests run in tasks, if the task fails, show an error message and make a new task for the next request.
- AlisdairO 12y agoYes, sorry - I wasn't meaning to state that rust is bad in this regard. Just addressing the point of catching NPEs and so on.
- alkonaut 12y ago
- Jweb_Guru 12y agoNot at all. Tasks can (and do) die without killing the main program. They also don't segfault, and as the stack unwinds destructors get called (which Rust can actually ensure is safe). If you've ever had the pleasure of dealing with a framework that likes to send SIGKILL indiscriminately to important programs, you'll appreciate the difference between the two.
- coldtea 12y agoNo. Something recoverable, like an exception. But it seems you have your mind set, and wont accept any other answer.
- dbaupp 12y agoIndexing a fixed-length array (I.e. known at compile time) out of bounds is not prohibited at compile time. All array types trigger a task failure on out-of-bounds access (unless you explicitly opt-in to unchecked indexing).
- guelo 12y agoI was going to ask if array[random_integer()] would compile only some of the time.
- b0b_d0e 12y agoOh thanks for clearing that up! Is there any specific reason why the rust compilier currently doesn't check that a static int accessing into a known length slice doesn't result in a compile error? (I'm only referring to cases where the index you are trying to access is known at compile time as well as the length of the slice)
- nikbackm 12y agoIt would be inconsistent and not really that helpful. How often do you use (invalid) constant indexes with fixed length arrays? Probably better to handle all out-of-bounds errors the same way.