The code for Fatal would be a good place to start. Plus, that hierarchy of exceptions would be better called Exception::Class::IO. The same list of exceptions (Cannot open, Cannot close, Cannot read, EOF, etc) can be applied to sockets, files, and the like.
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
| [reply] |
I looked at Fatal.pm code and found some semi-magic to dynamically get the prototype for the function(s) identified in the USE command. The code then dynamically build a new function to wrap around the caller's requested function in order to add the exception handling.
This is different from the approach taken by Exception::Class::DBI that was customized for DBI request, such as including extra fields for specific DBI diagnostic information:
use Exception::Class (
...< other exception classes > ...
'Exception::Class::DBI::STH' =>
{ isa => 'Exception::Class::DBI::H',
description => 'DBI statment handle exception',
fields => [qw(num_of_fields num_of_params
field_names
type precision scale nullable
cursor_name param_values
statement rows_in_cache)]
}
);
To get better diagnostic info, I think a customized approach like Exception::Class::DBI is needed for implementation.
I like your suggested exception name, Exception::Class::IO, to form individual exceptions: Exception::Class::IO::Open, Exception::Class::IO::Close, Exception::Class::IO::Read, etc. Short and very effective names. Correct?
However, the extra diagnostic fields needed for a disk file would be different for a socket. This leads me to believe I need something like Exception::Class::IO::File::Open or Exception::Class::IO::File::Close and a parallel set for sockets. Or am I missing something here?
Bill | [reply]
[d/l] |
Exception::Class::IO::Open::File vs. Exception::Class::IO::Open::Socket
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
| [reply] |