You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
autodie has too many features, weird interactions with Fatal, and internal methods that can be overridden. Adding internal exceptions is hard enough. Instead, make a new feature which causes all builtins to throw an exception on error. To ease forward compatibility a new CPAN module which is a wrapper around autodie (but does not reveal that) would be less problematic than trying to write a full autodie emulator.
All built in functions, not just IO. I don't think there's many outside IO. Basically anything that can return undef or print a warning is a candidate. Here's what I can think of right now...
eval STRING & evalbytes
If the code fails to compile.
That will break some eval idioms that are essentially "try this code". The trade off for protecting against code that's assumed to work is worth it.
File tests
If the file doesn't exist (except -e)
If the handle is closed or otherwise unreadable
If the stat or other important IO operation fails
This will break some file test idioms that assume you can do things like run -r on a file that doesn't exist. This may be a bad idea.
alarm?
printf, sprintf, pack, unpack
Invalid format/template
Invalid arguments for a given format
Missing arguments
substr
substring beyond the end of the string
caller
The level is off the stack
tie
TIEHASH fails to return an object.
gmtime, localtime
The given time is out of range
The text was updated successfully, but these errors were encountered:
autodie has too many features, weird interactions with Fatal, and internal methods that can be overridden. Adding internal exceptions is hard enough. Instead, make a new feature which causes all builtins to throw an exception on error. To ease forward compatibility a new CPAN module which is a wrapper around autodie (but does not reveal that) would be less problematic than trying to write a full autodie emulator.
All built in functions, not just IO. I don't think there's many outside IO. Basically anything that can return undef or print a warning is a candidate. Here's what I can think of right now...
eval STRING
& evalbytesThat will break some eval idioms that are essentially "try this code". The trade off for protecting against code that's assumed to work is worth it.
This will break some file test idioms that assume you can do things like run
-r
on a file that doesn't exist. This may be a bad idea.The text was updated successfully, but these errors were encountered: