Having a small helper that panics on all errors is fine for experimental
code, but not acceptable in production code.

The error in question can actually occur if rand.Reader is set to something
other than its default. If you're not planning to replace Reader, this
(without a helper) might be tolerable:

b := make([]byte, 32)
if err := rand.Read(b); err != nil {
    panic(err) // Can't happen. rand.Read just reads /dev/urandom.

-- depending on how confident you are that dev/urandom can be read without
error. If in doubt, just do the usual error handling and pass on the error.

On Wednesday, December 24, 2014 7:48:54 PM UTC+1, anl...@gmail.com wrote:

you can decouple the error handling to a separate file


if you need to return "" in a handler I suggest you my solution

wrap the caller and use Return() from the goerr library
this example shows how

On Wednesday, December 24, 2014 5:25:54 PM UTC+1, vax...@gmail.com wrote:


I have a program that uses the rand package to create some random
memory. However, handling the returned error from the Read function is
making the code a little cumbersome to use. Since the rand package is
writing to a byte array, is there any need to handle the error? It would
be nice if the error can be ignored.
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts


Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 4 of 4 | next ›
Discussion Overview
groupgolang-nuts @
postedDec 24, '14 at 4:25p
activeDec 25, '14 at 9:03p



site design / logo © 2022 Grokbase