Rust has a number of features that allow you to manage your code’s organization, including which details are exposed, which details are private, and what names are in each scope in your programs. These features, sometimes collectively referred to as the module system, include:
Collections can contain multiple values. Unlike the built-in array and tuple types, the data these collections point to is stored on the heap, which means the amount of data does not need to be known at compile time and can grow or shrink as the program runs. Each kind of collection has different capabilities and costs, and choosing an appropriate one for your current situation is a skill you’ll develop over time.
Rust’s commitment to reliability extends to error handling. Errors are a fact of life in software, so Rust has a number of features for handling situations in which something goes wrong. In many cases, Rust requires you to acknowledge the possibility of an error and take some action before your code will compile. This requirement makes your program more robust by ensuring that you’ll discover errors and handle them appropriately before you’ve deployed your code to production!
Rust groups errors into two major categories: recoverable and unrecoverable errors. For a recoverable error, such as a file not found error, it’s reasonable to report the problem to the user and retry the operation. Unrecoverable errors are always symptoms of bugs, like trying to access a location beyond the end of an array.
Rust doesn’t have exceptions. Instead, it has the type Result<T, E> for recoverable errors and the panic! macro that stops execution when the program encounters an unrecoverable error.
Package errors provides simple error handling primitives.
The traditional error handling idiom in Go is roughly akin to
1 | if err != nil { |
which applied recursively up the call stack results in error reports without context or debugging information. The errors package allows programmers to add context to the failure path in their code in a way that does not destroy the original value of the error.
Kotlin is a cross-platform, statically typed, general-purpose programming language with type inference. Kotlin is designed to interoperate fully with Java, and the JVM version of Kotlin’s standard library depends on the Java Class Library, but type inference allows its syntax to be more concise.
The Date Helper primarily creates select/option tags for different kinds of dates and times or date and time elements. All of the select-type methods share a number of common options that are as follows:
has_secure_password macro adds methods to set and authenticate against a BCrypt password. This mechanism requires you to have a XXX_digest attribute. Where XXX is the attribute name of your desired password.
request_store gives you per-request global storage.
Using request_store, the variables are stored in Thread.current, and that the storage is cleared after each request.
request_store-sidekiq provide an easy integration between RequestStore and Sidekiq.
RequestStore allows you to easily create threadsafe code, and this middleware for Sidekiq brings that functionality to Sidekiq workers, or even ActiveJob backed Sidekiq.
Package errors implements functions to manipulate errors.
The New function creates errors whose only content is a text message
The Unwrap, Is and As functions work on errors that may wrap other errors.
Import errors package.
1 | import "errors" |
1 | func New(text string) error |
New returns an error that formats as the given text. Each call to New returns a distinct error value even if the text is identical.
1 | // error message |
1 | func Unwrap(err error) error |
Unwrap returns the result of calling the Unwrap method on err, if err’s type contains an Unwrap method returning error. Otherwise, Unwrap returns nil.
If e.Unwrap() returns a non-nil error w, then we say that e wraps w.
A simple way to create wrapped errors is to call fmt.Errorf and apply the %w verb to the error argument:
1 | err := errors.New("error msg") |
returns err.
1 | func Is(err, target error) bool |
Is reports whether any error in err’s chain matches target.
The chain consists of err itself followed by the sequence of errors obtained by repeatedly calling Unwrap.
An error is considered to match a target if it is equal to that target or if it implements a method Is(error) bool such that Is(target) returns true.
An error type might provide an Is method so it can be treated as equivalent to an existing error. For example, if MyError defines
1 | func (m MyError) Is(target error) bool { return target == fs.ErrExist } |
then Is(MyError{}, fs.ErrExist) returns true. See syscall.Errno.Is for an example in the standard library.
Is unwraps its first argument sequentially looking for an error that matches the second. It reports whether it finds a match. It should be used in preference to simple equality checks:
1 | if errors.Is(err, fs.ErrExist) |
is preferable to
1 | if err == fs.ErrExist |
because the former will succeed if err wraps fs.ErrExist.
1 | err := errors.New("error msg") |
1 | func As(err error, target interface{}) bool |
As finds the first error in err’s chain that matches target, and if so, sets target to that error value and returns true. Otherwise, it returns false.
The chain consists of err itself followed by the sequence of errors obtained by repeatedly calling Unwrap.
An error matches target if the error’s concrete value is assignable to the value pointed to by target, or if the error has a method As(interface{}) bool such that As(target) returns true. In the latter case, the As method is responsible for setting target.
An error type might provide an As method so it can be treated as if it were a different error type.
As panics if target is not a non-nil pointer to either a type that implements error, or to any interface type.
1 | var perr *fs.PathError |
is preferable to
1 | if perr, ok := err.(*fs.PathError); ok { |
because the former will succeed if err wraps an *fs.PathError.
[1] errors - The Go Programming Language - https://golang.org/pkg/errors/
[2] Working with Errors in Go 1.13 - The Go Blog - https://blog.golang.org/go1.13-errors