Stories
Slash Boxes
Comments

NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

use Perl

All the Perl that's Practical to Extract and Report

All about App::Info More | Login | Reply

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Without JavaScript enabled, you might want to use the classic discussion system instead. If you login, you can remember this preference.

Structured exceptions? (Score:2)

by djberg96 (2603) on 2002.06.04 21:37 (#9135) Journal

Currently, if App::Info can't find the data it needs, it issues warnings. But this isn't the best approach, I think. Sometimes, you might want such errors to trigger exceptions. Other times, you might want them totally silent. So I was planning to add a flag to the API such that you can specify the behavior for such errors. Something like DBI's RaiseError or PrintError options. But then, it's just another step to add a prompting option. Such an option can be changed to prompt for new data at every step of the process, or only at important points (like finding the proper copy of httpd on the file system) or only when data can't be found.
What about using one of the structured Exception classes, so that people who create their own subclasses can create (and throw) their own exceptions based on the name of their module/subclass? Just a thought.

Reply to This
- Re:Structured exceptions? (Score:1)
  
  by Theory (10)
  
  Actually, that's more or less exactly what I was thinking of doing. The various subclasses would know what to do with a throw() depending on how the verbosity flag (for lack of a better word) was set.

Get More Comments

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.