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
Creating an OO module for interfacing with Perl's, let's say suboptimal approach of swallowing failures which should be thrown as exceptions, would have been the perfect solution of fixing those in a backcompat way.
Sadly Path::Class still returns undef on several methods instead of throwing exceptions.
Naively I thought that using autodie changes this behaviour which is doesn't.
Do you see a way of changing Path::Class' behaviour, lexically scoped so it doesn't break other modules, to either do so when autodie is used or by e.g. an import parameter?
The text was updated successfully, but these errors were encountered:
Yes, I think that could be achieved. Which methods in particular did you mean? The most common cases are handled by openr and openw - the idea being that it should be easier to do things the right way than the wrong way. But I'm sure there are other places that might usefully throw exceptions.
I use Path::Class::Dir->open to check if a directory exists and also Path::Class::File->open( O_CREAT | O_WRONLY | O_EXCL ) in ExtJS::Generator::DBIC::Model.
Creating an OO module for interfacing with Perl's, let's say suboptimal approach of swallowing failures which should be thrown as exceptions, would have been the perfect solution of fixing those in a backcompat way.
Sadly Path::Class still returns undef on several methods instead of throwing exceptions.
Naively I thought that using autodie changes this behaviour which is doesn't.
Do you see a way of changing Path::Class' behaviour, lexically scoped so it doesn't break other modules, to either do so when autodie is used or by e.g. an import parameter?
The text was updated successfully, but these errors were encountered: