[dancer-users] exceptional dancing

Ovid curtis_ovid_poe at yahoo.com
Thu Nov 20 12:07:10 GMT 2014

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").  
IT consulting, training, international recruiting
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 <wanradt at gmail.com> wrote:

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,

dancer-users mailing list
dancer-users at dancer.pm

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.preshweb.co.uk/pipermail/dancer-users/attachments/20141120/e3dcece6/attachment.html>

More information about the dancer-users mailing list