Az elso kettovel nem vitatkozom (az 1.-ben igazad van, a 2. velemenyes, es tiszteletben tartom a te velemenyedet).
A determinisztikussag/nemdeterminisztikussag: ha en egy eroforrast reprezentalok egy osztallyal, akkor tudom *garantalni* azt, hogy felszabadul, amint az objektum elerhetetlenne valik?
1. Erzesem szerint c++-ban igen:
class Resource : public non_copyable {
public:
Resource() : some_fd(open(...)) {}
private:
int some_fd;
};
void foo() {
Resource r;
...
}
A C++ runtime garantalja, hogy az objektum destruktora meghivodik. Azaz akarmit csinalsz foo fuggveny implementalasakor az r fuggveny felszabadul.
2. A Java valami ilyesmi lehet:
void foo() {
try (Resource r = new Resource()) {
...
}
}
Ezt en nem nevezem automatikusnak es jol vegiggondoltnak. Mert mi van:
1. Ha a kedves user elfelejti, hogy ez egy Closeable objektum? Tehat nem teszi oda a try blokkot... Valamikor felszabadul az eroforras, de hogy mikor azt nem tudjuk. Es itt ne csak memoriat nezzunk sokkal veszelyesebb tud ez lenni lock-okkal. Lehet, hogy az osszes teszt soran nem lesz gond, a production rendszer meg alkalmankent deadlock-ol.
2. (Ez egy kevesbe elmeleti, de szerintem cikisebb problema): A Resource osztaly csak refactoring soran valt Closeable osztallya. Akkor vegig kell menni az osszes felhasznalason es manualisan kell try blokkokkal korbevenni.
Tehat ujrafogalmazom a dolgot: az eroforras felhasznalojanak figyelmessegen mulik, hogy az eroforras determinisztikusan (scope-ot elhagyva rogton) vagy nemdeterminisztikusan (gc altal valamikor kesobb) szabadul fel.