You'll actually find a fair amount of disagreement over how to handle
exceptions. In fact, some argue to never handle them and instead let them
bubble up to the top on the theory that they'll show up in your error logs and
you'll have no choice but to deal with them. The alternative is having
exceptions get swallowed, hiding real errors, and having your app do strange
things. Here's a classic anti-pattern from Java from a dev who's in a hurry:
try { CopyFiles(); MakeRegistryEntries(); } catch
(CException & e) { // I'll come back to this later }
Because exceptions must often be trapped at compile-time in Java, you'll often
find bad java code with empty catch blocks "swallowing" exceptions on the
theory that they have a lot of work to do and will come back to it later.
Later, of course, is always later. The app fails mysteriously when other devs
are trying to why the copied files are intermittently not copied.
In Perl, we don't have "checked exceptions" like we do in Java, but here's how
it manifests:
try { copy_files(); make_registry_entries(); } catch {
my $error = $_; $self->log->error($error); };
Well, great. We've logged the damned error, but the software didn't see it and
many people don't look at the logs. By never trapping errors, they become big
IN YOUR FACE errors and are pretty hard to ignore.
Moving away from that point of view, there are fundamentally two types of
exceptions: those you can recover from and those you cannot. For many Web-based
applications, failure to connect to the database is an unrecoverable error.
Don't trap it: let it bubble up and make sure your user gets a really pretty
500 page (not the development 500 page with a stack trace. Major security hole!)
For recoverable errors (particularly low-value ones), such as failing to fetch
a funny quote from the fortune command, I would trap it at the source, log the
error, and make sure my app is coded in such a way that it can handle the lack
of "fortune" output (perhaps by providing a default "fortune").
Best,Ovid--
IT consulting, training, international recruiting
http://www.allaroundtheworld.fr/.
Buy my book! - http://bit.ly/beginning_perl
Live and work overseas - http://www.overseas-exile.com/
On Thursday, 20 November 2014, 12:29, WK <[email protected]> wrote:
Hi!
I have no real experience using exceptions in my code. Neither I have not seen
good guide how to use exceptions in software developent. I have lot of small
pieces about it, but no big picture. So I have simple question: how and where
to catch errors in Dancer app?
I looked to Dancer::Error and it seems good, but still I don't get, where is
the best place to catch and handle errors? Is it good idea to have one simple
dispatcher (like in bin/app.pl), so every exception is falling to the base
script and handled there? Or is better to catch them in place all over the
code? Or? Is there some "best practice"?
--
Wbr,Kõike hääd,
Gunnar
_______________________________________________
dancer-users mailing list
[email protected]
http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
_______________________________________________
dancer-users mailing list
[email protected]
http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
