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)]
    }
);
[download]

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