2.0.3: More robust against wrong placeholder values

Summary

Release 2.0.3 of error-reporting-lua improves the robustness of the error reporting. While it should not happen that users provide tables, userdata or threads as values for placeholders, accidents happen. You won't get any particularly useful info out of the value, but at least you still want to see the error message.

Bugfixes

• #35: Made robust against tables, userdata and threads in placeholder values.

2.0.2: Fixed outdated links

Summary

Release 2.0.2 of error-reporting-lua fixes outdated links in the documentation.

Bugfixes

• #31: Fixed outdated links.

2.0.1: Fixed module name case

Summary

Release 2.0.1 of error-reporting-lua fixes inconsistencies between source filename, table name and module name case that led to unresolvable dependencies.

Importing a module is now done with:

local ExaError = require("ExaError")

Bugfixes

• #20: Fixed using boolean message parameters
• #22: Fixed uninitialized mitigation list when using new

Refactoring

• #22: Streamlined object constructors. Applied coding style. Upper camel case for classes.

2.0.0: Streamlined interface

Summary

Release 2.0.0 of error-reporting-lua fixes a bug that caused an error when you used a boolean value as message parameter.

We also streamlined the interface. The create factory method is now gone and the new method was simplified. This unfortunately results in a breaking change, which is also the reason we increased the major number.

In the course of reworking the new method we also fixed a bug caused by an uninitialized mitigation in case the object was created with new instead of create.

To comply with our style guide we changed the class names to upper camel case: ExaError and MessageExpander. Another breaking change.

Of course, we updated the user guide accordingly.

We migrated the unit tests to the busted framework. You can now run the tests with either:

busted

or

luarocks --local test

We replaced the GitHub action for installing Lua with the standard apt-get solution, now that the GitHub Ubuntu runner 22.04 is available with Lua 5.4.

How to Migrate Your Code

1. Replace exaerror by ExaError as module and class name
2. If you used the message expander directly (which is usually not necessary), replace message_expander by MessageExpander
3. Replace calls to create with new, keeping the parameter signature
4. If you have pre-initialized object-style new calls, replace the table with the attributes code, message, parameters and mitigations by a flat list of the values. Mind the parameter order!
5. Note that new now accepts mitigations as optional fourth parameter.

Bugfixes

• #20: Fixed using boolean message parameters
• #22: Fixed uninitialized mitigation list when using new

Refactoring

• #22: Streamlined object constructors. Applied coding style. Upper camel case for classes.

Version 1.2.2: Support Lua 5.4

error-reporting-lua 1.2.2, released 2022-03-03

Code name: Support Lua 5.4

Summary

Release 1.2.2 of error-reporting-lua adds support for Lua 5.4.

Feature

• #75: Added support for Lua 5.4

Dependency Updates

• Added lua:5.4

Pipe replaced

Summary

Release 1.2.1 of error-reporting-lua replaces the pipe symbol "|" in the source code with string.char(124) to improve compatibility with environments where the pipe symbol in source produces an error.

Refactoring

• #15: Replaced pipe symbol

Stack trace control

Summary

Release 1.2.0 of error-reporting-lua adds control over which parts of the stack trace are used as location information for the raised errors.

The raise method now has an optional parameter that decides on which level of the stack trace is reported as the error location. Or if a location should be reported at all.

Features

• #13: Stack trace control

Ticket mitigation

Summary

Release 1.1.0 of error-reporting-lua adds a new convenience method add_ticket_migitation() to the error object builder. You can use this method to add a mitigation to the error that tells the user to create an issue ticket.

This is useful in cases where an error should theoretically be impossible to happen, but happened nonetheless, which clearly indicates a software error that needs to be addressed by the software maker.

We also changed the way errors are raised. Instead of throwing the error object, we now throw the message. This improves compatibility with existing error handling mechanisms.

Features

• #9: Added ticket mitigation

Bugfixes

• #11: Raise error with string instead of error object

Fixed rockspec

Summary

Release 1.0.1 of error-reporting-lua fixes a mistake in the rockspec, the manifest that decides what goes into the delivery package. The mistake kept the actual Lua module from being packaged.

Features

• #7: Fixed rockspec

Minimum Viable Product

Summary

Release 1.0.0 contains of the exaerror Lua module that allows defining uniform error objects and raising them as Lua error.

An error object can contain an error code, a description and one or more mitigation hints. Description and mitigations can contain parameters that get replaced at runtime.

Error objects can be used in places where Lua expects strings (e.g. in concatenations).

Features

• #1: Basic error object and builder
• #3: Placeholders in mitigations
• #4: Parameter descriptions