Better Error Logging with Frappe
Bad Error Handling is one of the toughest problems in software architecture and a reason for most breakdowns
Software code is usually designed to run in a certain way, with certain inputs. If the code does not receive correct input (or any input!) then it fails. For example a wrong Customer ID will cause your Invoice to fail.
Most software is designed to handle such cases, but this is not as easy as it sounds. For example detecting a bad email id is a hard problem.
When we build applications with a user interface, these bad inputs are easy to identify and protect the user against. Also the result of a bad error is immediately visible to the user or tester who reports it back to the developer.
But when we design systems that talk to other systems, these errors often go un-noticed and happen at odd times, when there is no user to observe or report it. Hence when dealing with integrations, error handling becomes very critical.
In Frappe, so far we had a mixed system for Error Handling. There was the Scheduler Log* that got updated when something failed, and Max Morias' *Error Snapshot that detected errors at a much deeper level. For a developer to explicitly log errors, there was no simple mechanism.
So we are now introducing the Error Log which is a renamed Scheduler Log. This is the default place for a software to report when something fails.
To call it, from code you can just write:
frappe.log_error(frappe.get_traceback(), 'payment failed')
This will immediately log it into the Error Log table (which is MyISAM type, so you need not commit) and can be viewed by the user or administrator.
Bad Error Handling is one of the biggest reasons for software to fail and as ERPNext keeps building more integrations, it is important to improve the error handling code!
Rushabh is a software developer and founder of ERPNext. He usually writes about the startup experience, open source and the technologies he is working on.