DEV Community: Vasyl Pominchuk

Recover in Go. Panic and Recover in Golang

Vasyl Pominchuk — Sat, 02 Dec 2023 04:15:30 +0000

Difference Between throw/catch in Other Languages
Understanding defer() Function
Understanding panic() Function
How to recover()

Difference Between throw/catch in Other Languages

Before we dive into Golang's error recovery mechanisms, let's briefly touch on the more traditional "throw" and "catch" paradigm found in languages like PHP, Java, JavaScript and so on. In those languages, an exception (or error) is thrown when a runtime error occurs, and it propagates up the call stack until it's caught by an appropriate try/catch block.

In contrast to languages like PHP, Java and JavaScript, Golang adopts a unique approach to error handling by emphasizing explicit error handling through return values. In Golang, functions typically return both a result and an error, empowering developers to explicitly check for and manage errors at each step. This approach provides greater control over the program's flow, diverging from the traditional "throw" and "catch" paradigm found in other languages.

Golang introduces panic, defer, and recover as alternatives to the throw and catch concepts. While these mechanisms share a common ground, they differ in important details, offering a more explicit and controlled approach to error handling in Golang.

Understanding defer() Function

One of Golang's distinctive features is the defer() function, which allows you to schedule a function call to be executed after the surrounding function returns. This can be particularly useful for tasks like closing files, releasing resources, or, as we'll see, handling panics.

When multiple defer statements are used within a function, they are executed in reverse order, i.e., the last defer statement is executed first, followed by the second-to-last, and so on. The execution order is essentially a Last In, First Out (LIFO) stack.

Here's an example to illustrate the execution order of multiple defer statements:

package main

import "fmt"

func exampleFunction() {
    defer fmt.Println("Deferred statement 1")
    defer fmt.Println("Deferred statement 2")
    defer fmt.Println("Deferred statement 3")

    fmt.Println("Regular statement 1")
    fmt.Println("Regular statement 2")
}

Regular statement 1
Regular statement 2
Deferred statement 3
Deferred statement 2
Deferred statement 1

As you can see, the deferred statements are executed in reverse order after the regular statements. This behavior is useful in scenarios where you want to ensure certain cleanup tasks or resource releases are performed, regardless of the flow of execution within the function.

Understanding panic() Function

In Golang, the panic() function is used to trigger a runtime panic. When a panic occurs, the normal flow of the program is halted, and the program starts unwinding the call stack, running any deferred functions along the way.

func examplePanic() {
    // some logic
    if somethingBad {
        panic("Something bad happened!") // panic is triggered
    }
    // rest of the function logic
}

While panics might seem disruptive, they serve a crucial purpose in signaling unrecoverable errors or exceptional conditions. When a panic() is triggered, it enters a panicking mode, initiating the execution of deferred functions and unwinding the call stack.

Panics can be initiated either directly by calling panic() with a single value as an argument, or they can be caused by runtime errors.
One common runtime error in Golang is attempting to access an index that is out of bounds in a slice. Here's an example that causes a runtime error:

package main

import "fmt"

func main() {
    // Creating a slice with three elements
    numbers := []int{1, 2, 3}

    // Accessing an index that is out of bounds
    outOfBoundsIndex := 5
    value := numbers[outOfBoundsIndex] // This line will cause a runtime error

    // This line won't be reached due to the runtime error
    fmt.Println("Value at index", outOfBoundsIndex, "is:", value)
}

In this example, the numbers slice has three elements, but we attempt to access the element at index 5, which is beyond the length of the slice. When the program is run, it will result in a runtime error similar to:

panic: runtime error: index out of range [5] with length 3

This panic occurs at runtime, and if not handled, it would terminate the program. Handling such runtime errors is crucial in real-world applications.

How to recover()

To gracefully handle panics and potentially recover from them, Golang provides the recover() function. When used in conjunction with defer, recover() allows you to capture the panic value and resume normal execution. If we are in panicking mode, the call to recover() returns the value passed to the panic function.

func main() {
    defer func() {
        if r := recover(); r != nil {
            // handle the panic
            fmt.Println("Recovered from panic:", r)
        }
    }()
    // rest of the function logic that might panic
}

In the example above, the recover() function is used to capture the panic value, which is then printed as part of the recovery process. It's important to note that recover() only works when called directly from a deferred function. If there is no panic or if recover() is called outside the context of deferred functions during panicking, it returns nil.

In real world applications you will face with problems of converting panic to normal error, this is the same that try/catch do for us.

package main

import (
    "fmt"
)

func exampleRecoverToError() (err error) {
    defer func() {
        if r := recover(); r != nil {
            // convert panic to an error
            err = fmt.Errorf("panic occurred: %v", r)
        }
    }()

    // rest of the function logic that might panic
    panic("Something went wrong!")

    // This line won't be reached due to the panic
    return nil
}

func main() {
    if err := exampleRecoverToError(); err != nil {
        fmt.Println("Error:", err)
    } else {
        fmt.Println("No error.")
    }
}

In the example above we recover our application from panicing mode and convert from panic to normal error using named return technic.

Understanding that the call to recover() returns the value passed to the panic function allows for more nuanced and context-aware recovery mechanisms, enabling you to inspect and respond to specific panic conditions within your Golang application.

Kindly visit my personal website for additional intriguing content.

Conclusion

Understanding and mastering error recovery in Golang is crucial for writing robust and reliable applications. The combination of defer(), panic(), and recover() provides a powerful mechanism for handling errors gracefully and ensuring your applications remain resilient even in the face of unexpected issues. By employing these techniques, you can elevate your error-handling game and build more robust Golang applications.

Infinite Scroll for Vue3. Yet another component.

Vasyl Pominchuk — Fri, 11 Nov 2022 12:06:30 +0000

vue-infinite-scroll is a super simple and lightweight package allowing you to implement infinite scroll for your project in a second.

Just type
npm i @vpominchuk/vue-infinite-scroll

and use it as:
<infinite-scroll :active="true" distance="50px" auto-load="true" @process="load" />

<infinite-scroll /> component has a few properties to change the behavior.

Properties

Property	Type	Description
active	Boolean	Enable / Disable Component
distance	String	Distance from the bottom side of the page when component fires `@process` event to load the content. "200px" is a good enough, but you can choose any other value.
auto-load	Boolean	Fire @process event on component mount

Event

Property	Description
@process	Callback function - fires when user scrolls to the bottom side of the page. Load a new portion of your content here.

Sample

Sample is available under dev folder.

To try the sample, create a new folder out of your project.
Install vue-infinite-scroll package and run npm run serve

mkdir vue-infinite-scroll-exampe
cd vue-infinite-scroll-exampe
npm i @vpominchuk/vue-infinite-scroll
cd node_modules/@vpominchuk/vue-infinite-scroll/
npm i
npm run serve

If you are using Windows platform try
npm run serve-win

Open http://localhost:8080/ in your favorite browser

Remove node_modules inside @vpominchuk/vue-infinite-scroll/ after tests.

Github page:
https://github.com/vpominchuk/vue-infinite-scroll

Enjoy :)

Laravel Cache: Improve performance of your application

Vasyl Pominchuk — Tue, 21 Jun 2022 14:44:39 +0000

Hi guys,
today I wanna talk about application performance improvement in terms of Caching.

Caching is a strategy where you store a copy of the data in front of the main data source.
Advantages of caching include faster response time and the ability to serve data quickly, which can improve performance of your application and user experience.

Do you really need a cache in your application? Personally, I say yes. You do need it.

If we decompose our application into blocks we get the following picture:

DB block is an our applications main database engine, such as MySQL, PostgreSQL, MariaDB and so on.
Another DataSource block is an optional datasource, like external search engine, such as ElasticSearch and so on. You may or may not have it in your application.
File Storage - we always have file storage, for our resources or static files.
View block, it can be either template engine, like Laravel Blade or Smarty OR it can be React, Angular or VueJS view with their own application server or prerenderer. It can be even some API client and in this case we can say that our "view" is a response to any incoming API call.

In this article, we will mainly talk about caching results from Database.

One major point: before making a decision to use Cache make sure you have optimized your SQL queries, it makes no sense to left your SQL queries not optimized and try to resolve this problem due to caching.

If we making queries to really big tables with complex where clauses, with joins and so on, it may take a while to retrieve the result. And this is a good place to cache it.



public function getProductsBlock(int $limit = 5)
{
    return Products::query()
        ->indexed()
        ->whereHas("images", function(Builder $query) {
            $query->active();
        })
        ->with("images")
        ->with("comments")
        ->with("ratings")
        ->with("attributes")
        ->orderBy('id', 'desc')
        ->limit($limit)
        ->get();
}

For example, we have enough complicated query with a subquery, four relations, one orderBy and even "limit".
It is a dummy query it doesn't work, it just for example.
Let's see how we can cover it with a Cache.



public function getProductsBlock(int $limit = 5)
{
    $cacheKey = "products_block_" . "_" . $limit;
    $ttl = 600; // 10 minutes.

    return Cache::remember($cacheKey, $ttl, function() use ($limit) {
        return Products::query()
            ->indexed()
            ->whereHas("images", function(Builder $query) {
                $query->active();
            })
            ->with("images")
            ->with("comments")
            ->with("ratings")
            ->with("attributes")
            ->orderBy('id', 'desc')
            ->limit($limit)
            ->get();
    });
}

Ok, now our data in a cache and we can retrieve it as fast as lightning and not bother our database.

But what if data has been changed?
If we call getProductsBlock() it returns us data from the cache and it won't be up to date now.

How to deal with this and how to choose correct TTL (Time To Live) for our cache function I told in this video.

Please like and subscribe to my channel, you will motivate me to create new videos. If you have any questions, please ask in comments on Youtube.

Laravel: How to use `USE INDEX` and `FORCE INDEX` for Eloquent and MySQL

Vasyl Pominchuk — Sun, 12 Sep 2021 13:22:12 +0000

Eloquent - is a powerful class for working with databases, easily extensible and easy to use. But sometimes it is necessary to get a little more than the developers have provided for at the moment.

Some time ago I was investigating a problem with MySQL indexes on a big table and realized that there is no way to build a query with use index or force index statements using Laravel Eloquent class.

This is why I have tried to fix it :)

Let me introduce a simple Laravel package to cover these needs:
https://github.com/vpominchuk/laravel-mysql-use-index-scope

Installation

composer require vpominchuk/laravel-mysql-use-index-scope

Usage

Simply reference the required trait in your model:

Model

use VPominchuk\ModelUseIndex;

class MyModel extends Model
{
    use ModelUseIndex;
    ...
    ...
}

Anywhere in the code:

$builder = MyModel::where('name', $name)->where('age', $age)->
        useIndex($indexName)->...

MySQL Indexes

Don't forget to create a named index with Laravel migration:

$table->index(['name', 'age'], 'user_age_index');

Available methods

useIndex($indexName)
Tells MySQL to use an index if it possible.

forceIndex($indexName)
Force MySQL to use an index if it possible.

Please check my personal blog for new articles:
https://pominchuk.com/posts