Re^3: Error handling in Mojolicious

Adding checks for all these possibilities would be rather painful.

A long-winded version of what others have said (or implied) more succinctly.

Writing code for exception handling is work, and work can be painful. But what's the alternative? Put your code into production without exception handling and hope it never fails? Dream on. (I assume we're talking about some sort of production application.)

So what happens when your code fails without giving you the information you might get from even minimal exception handling? (Even a simple die statement will at least localize the failure to a particular line of source in a particular file.) Then you add checks for all the possible failures that might occur until you track down the culprit; i.e., you end up doing what you should have done to begin with. Add to this the fact that you may be doing all this at 3 AM because the production application needs to be ready for start-of-business at 8 AM and you learn what pain really is!

If it's production code, it needs to be professional code, and professional code handles (or at least considers the handling of) errors.

Update: Small wording change for clarity.

Give a man a fish: <%-{-{-{-<

Comment on Re^3: Error handling in Mojolicious Download Code

Replies are listed 'Best First'.
Re^4: Error handling in Mojolicious by davido (Cardinal) on Jul 08, 2021 at 19:00 UTC
You called out the classic "Anyone can write a blog in a day" (or in a hackathon) paradox. It's easy to ignore all the hard parts and feel highly productive accomplishing a proof-of-concept in a short period of time. It usually turns out the POC is fairly trivial if it gets to ignore all the time consuming parts of the problem such as error handling, parameter validation, security, CICD pipelines, automated testing, documentation, and fitting into a larger ecosystem. Dave	[reply]

Replies are listed 'Best First'.

Re^4: Error handling in Mojolicious
by davido (Cardinal) on Jul 08, 2021 at 19:00 UTC

You called out the classic "Anyone can write a blog in a day" (or in a hackathon) paradox.

It's easy to ignore all the hard parts and feel highly productive accomplishing a proof-of-concept in a short period of time. It usually turns out the POC is fairly trivial if it gets to ignore all the time consuming parts of the problem such as error handling, parameter validation, security, CICD pipelines, automated testing, documentation, and fitting into a larger ecosystem.

Dave

[reply]