Re: Error handling in a module

G'day Bod,

Many modules use a similar system to DBI. Text::CSV has the error_diag() method. The core modules in the IO::Compress:: namespace also do this: IO::Compress::Zip has $ZipError; IO::Compress::Bzip2 has $Bzip2Error; and so on. There are many other examples; it's a tried and tested model; there's certainly nothing wrong with using this approach.

Some of your points seem to indicate a single action to handle exceptions; I'd suggest there should be at least two: how you present problems to the user and how you present problems to the maintainer.

I don't know enough about your system but writing to STDERR should generally add to error_log (or similar). This is useful for the maintainer for troubleshooting; it wouldn't normally be available to the user.

Having some form of error page, or popup error panel, is what you should be presenting to the user. You can add a direction to include the message in a report to a sysadmin; but maintainers shouldn't rely on receiving this.

In addition to these "at least two", other actions such as emailing a report, or texting a notification, to a sysadmin may be appropriate.

How you present feedback to users will largely depend on the severity of the problem.

For a fatal error, an error page might have something like: "Database connection failed. Administrators have been notified. Please try again later.".

For problems with credentials (authentication or authorisation) you'd generally want to repost the page with an added message. A fairly typical example would be "Username/password mismatch. Please try again.". There might be a timeout or retry limit; it may be appropriate to advise the user of these.

There are situations where many things need to be validated; in a web context, this will often be a form. I tend to check as much as possible then present the user with a list of problems; e.g. "Name field is required", "Invalid date (31st November)", and so on. This allows the user to fix many things at once; presenting these one at a time can be very annoying. These messages might appear separately against individual form fields; they could be presented together in a list in a popup error panel; you might choose both of those.

I've aimed to keep my response as general as possible. If you have specific questions, please ask separately.

— Ken

Comment on Re: Error handling in a module Select or Download Code

Replies are listed 'Best First'.
Re^2: Error handling in a module by Bod (Parson) on Feb 27, 2023 at 00:23 UTC
Hi Ken Thanks as always for your very helpful reply Some of your points seem to indicate a single action to handle exceptions; I'd suggest there should be at least two: how you present problems to the user and how you present problems to the maintainer You are right, I am thinking here of just one form of error handling... This is because I am writing a module that will help others deal with the end user - the person browsing the website. The module is only concerned about providing error reporting to the programmer using it in something bigger. It is up to them to provide suitable messaging to the end user. It is up to me to make it easy for them to do that. Of course, I am writing this module because it is something I want to use. So, in the first instance, I will be both using the error reports from the module and serving more helpful error reports to the end user.	[reply]

Replies are listed 'Best First'.

Re^2: Error handling in a module
by Bod (Parson) on Feb 27, 2023 at 00:23 UTC

Hi Ken

Thanks as always for your very helpful reply

Some of your points seem to indicate a single action to handle exceptions; I'd suggest there should be at least two: how you present problems to the user and how you present problems to the maintainer

You are right, I am thinking here of just one form of error handling...

This is because I am writing a module that will help others deal with the end user - the person browsing the website. The module is only concerned about providing error reporting to the programmer using it in something bigger. It is up to them to provide suitable messaging to the end user. It is up to me to make it easy for them to do that.

Of course, I am writing this module because it is something I want to use. So, in the first instance, I will be both using the error reports from the module and serving more helpful error reports to the end user.

[reply]