Meck Error: `non_strict` And `unstick` Options Combined

Oct 24, 2025 by SLV Team 56 views

Hey guys! Let's dive into a quirky little issue encountered while using the Meck mocking library in Erlang. It's about the somewhat cryptic error that pops up when you try to combine the non_strict and unstick options in meck:new/2. Buckle up, it's going to be an interesting ride!

The Curious Case of `non_strict` and `unstick`

So, our user stumbled upon an error while experimenting with Meck, specifically when calling meck:new/2 with both the non_strict and unstick options. The error message wasn't exactly a beacon of clarity, leading to a bit of head-scratching. Here’s the snippet of the error:

=CRASH REPORT==== 24-Oct-2025::09:45:32.846808 ===
  crasher:
    initial call: meck_proc:init/1
    pid: <0.1266.0>
    registered_name: []
    exception error: no match of right hand side value {error,nofile}
      in function  meck_proc:init/1 (/home/mmin/invariant/tw_core_lib/_build/test/lib/meck/src/meck_proc.erl:216)
      in call from gen_server:init_it/2 (gen_server.erl:2276)
      in call from gen_server:init_it/6 (gen_server.erl:2236)
    ancestors: [<0.1264.0>,<0.1226.0>,<0.1225.0>,user_drv,<0.70.0>,<0.66.0>,
                  kernel_sup,<0.47.0>]

Now, if you're anything like me, you'd agree that “no match of right hand side value {error,nofile}” isn't the most helpful message in the world. It's like getting a cryptic fortune cookie – technically it's there, but it doesn't really tell you anything useful.

Understanding the Root Cause is the first step to addressing any issue. When developers encounter errors like this, especially in testing scenarios, the feedback needs to be crystal clear. Imagine spending hours debugging, only to find out the problem was a simple, preventable conflict between two options! The current error message leaves much to be desired, making it harder for developers to quickly identify and resolve the issue. This can lead to frustration and wasted time, which is something we all want to avoid. So, let's dig a little deeper into why this might be happening. The error suggests a mismatch or conflict within the internal workings of Meck, specifically in the meck_proc:init/1 function. This is where the process for a mock is initialized, and it seems the combination of non_strict and unstick is throwing a wrench in the gears. We need to understand what these options do individually and why their combination is problematic.

Diving Deep: `non_strict` and `unstick` Explained

Let's break down what these options actually do in Meck:

non_strict: This option tells Meck to be more lenient with the calls made to your mocked functions. In strict mode (the default), Meck expects calls to happen exactly as you've defined them – same arguments, same order, everything. non_strict relaxes this, allowing you to call mocked functions with different arguments or in a different order than initially specified. Think of it as saying, “Hey Meck, I might call this function in various ways, so don't be too picky.”
unstick: This one’s a bit more about the lifecycle of your mocks. Normally, when you mock a function with Meck, that mock stays in place until you explicitly unmock it. unstick makes the mock automatically disappear after the first call. It's like a one-time-use mock – perfect for scenarios where you only need to intercept a function call once.

So, why do these two clash? Well, the core of the issue likely lies in the conflicting expectations they set. non_strict says, “I might call this function in many ways,” while unstick says, “I'm only going to allow one call.” This creates a logical conflict. If a mock is set to unstick after the first call, the flexibility offered by non_strict becomes irrelevant. It’s like buying a versatile Swiss Army knife and then only using one specific tool once – the other features are rendered useless.

The Heart of the Problem: Why the Error?

The underlying problem seems to stem from how Meck manages its internal state and expectations when these options are combined. The error message, “no match of right hand side value {error,nofile}, ” suggests a pattern-matching failure deep within Meck's internal logic. This probably happens because the combination of non_strict and unstick leads to an unexpected state that Meck's code doesn't account for. When meck_proc:init/1 tries to initialize the mock process with these options, it encounters a condition it's not prepared to handle, resulting in the crash.

This is a classic example of a combinatorial issue, where the interaction of two features (in this case, non_strict and unstick) creates an unforeseen problem. Each option works fine on its own, but when used together, they trigger a bug. This type of issue can be particularly challenging to debug because it’s not immediately obvious why the error is occurring. You might test each option individually and find no problems, only to have the system crash when you combine them.

A Call for a Better Error Message

The user who reported this issue rightly pointed out that the error message is less than ideal. It doesn't clearly communicate the problem, leaving developers in the dark. A better error message could save a lot of time and frustration. Instead of a cryptic message about a “no match, ” a message like, “Error: The non_strict and unstick options cannot be used together,” would be infinitely more helpful.

Crafting a User-Friendly Error

So, what makes a good error message? Here are a few key characteristics:

Clarity: The message should clearly state what went wrong. Avoid technical jargon and internal implementation details.
Specificity: The message should pinpoint the exact cause of the error. In this case, it should explicitly mention the conflicting options.
Guidance: The message should offer some direction on how to fix the problem. For example, it could suggest alternative approaches or explain why the combination is invalid.

In the context of Meck, a good error message for this scenario might look like this:

Error: Invalid options combination.
The `non_strict` and `unstick` options cannot be used together in meck:new/2.
`non_strict` allows flexible function calls, while `unstick` removes the mock after one call. These options have conflicting behaviors.
Please choose either `non_strict` or `unstick`, or consider alternative mocking strategies.

This message is clear, specific, and provides guidance. It tells the user exactly what the problem is, why it's happening, and suggests a way forward. This is the kind of feedback that empowers developers to quickly resolve issues and get back to coding.

Where to Implement the Fix

The user also suggested a great place to implement this improved error message: after the meck_proc:validate_options/1 call. This function is likely responsible for checking the validity of the options passed to meck:new/2. By adding a check specifically for the non_strict and unstick combination within this function, we can catch the error early and provide a more informative message.

This approach aligns with the principle of fail-fast, which advocates for detecting and reporting errors as soon as possible. By validating options upfront, we prevent the system from entering an inconsistent state and crashing with a cryptic error later on. This not only improves the developer experience but also makes the system more robust and easier to debug.

Documentation is Key

In addition to a better error message, this issue highlights the importance of documentation. If the Meck documentation clearly stated that non_strict and unstick should not be used together, this error could have been avoided in the first place. Documentation serves as a crucial resource for developers, providing guidance on how to use a library or tool effectively. It should cover not only the basic usage but also potential pitfalls and limitations.

What to Include in the Documentation

For Meck, the documentation should include a clear explanation of each option available in meck:new/2, including non_strict and unstick. It should also explicitly state that these two options are incompatible and explain why. A simple note or warning in the documentation could save developers a lot of time and frustration.

Here’s an example of how this could be documented:

non_strict

Allows flexible function calls to the mock. The mock will accept calls with different arguments or in a different order than initially specified.

unstick

The mock is automatically removed after the first call.

Warning: The non_strict and unstick options should not be used together. non_strict allows for multiple flexible calls, while unstick removes the mock after the first call. This combination results in conflicting behaviors.

By including this information in the documentation, Meck can help developers avoid this pitfall and use the library more effectively. Good documentation is not just about listing the available functions and options; it’s about providing context, guidance, and warnings to ensure users have a smooth and productive experience.

A Potential PR to the Rescue

The user who reported this issue also generously offered to create a pull request (PR) to fix it. This is the spirit of open-source at its finest! A PR is a contribution to a project, typically involving code changes, documentation updates, or bug fixes. In this case, a PR could address the following:

Improved Error Message: Implement a more informative error message when non_strict and unstick are used together.
Option Validation: Add a check in meck_proc:validate_options/1 to detect this invalid combination.
Documentation Update: Add a note to the Meck documentation explaining the incompatibility of these options.

The Power of Community Contributions

Community contributions like this are invaluable to open-source projects. They bring diverse perspectives, expertise, and effort to the table, making the project stronger and more user-friendly. By submitting a PR, the user is not only fixing a bug but also helping other developers avoid the same issue in the future. This collaborative approach is what makes open-source so powerful.

If you're new to open-source, contributing to a project like Meck can be a great way to learn and grow. It allows you to work on real-world problems, collaborate with experienced developers, and make a tangible impact. Don't be afraid to jump in and contribute – your help is always welcome!

Wrapping Up

So, there you have it – the tale of the non_strict and unstick combo error in Meck. It’s a great example of how seemingly small issues can lead to valuable learning opportunities. By improving the error message, updating the documentation, and addressing the underlying code, we can make Meck an even better tool for Erlang developers. And remember, clear communication, detailed documentation, and community contributions are key to building robust and user-friendly software. Keep those mocks clean and your tests green, guys! Happy coding!