Piszę własną prostą implementację javax.sql.DataSource
, jedyną metodą, którą muszę wykonać, jest getConnection: Connection
, ale interfejs dziedziczy wiele innych metod (których nie potrzebuję) od javax.sql.CommonDataSource
i java.sql.Wrapper
. Tak więc chciałbym "wdrożyć" te niepotrzebne metody w taki sposób, w jaki one by nie działały, ale zachowałyby się w odpowiedni sposób po wywołaniu. Na przykład zaimplementować boolean isWrapperFor(Class<?> iface)
jakJak zwrócić wartość null z ogólnej funkcji w Scali?
def isWrapperFor(iface: Class[_]): Boolean = false
i chciałbym wdrożyć <T> T unwrap(Class<T> iface)
jako
def unwrap[T](iface: Class[T]): T = null
Ale ostatnio nie działa: sprawozdania kompilatora niezgodność typów.
Czy będzie prawidłowe stosowanie null.asInstanceOf[T]
, czy jest lepszy sposób? Oczywiście uważam, że zamiast tego rzucam UnsupportedOperationException
w tym konkretnym przypadku, ale IMHO pytanie wciąż może być interesujące.
Nie było nowości, że w Scali są nie-nullowalne typy ... Myślałem, że 'Int' jest zerowalne w przeciwieństwie do prymitywnej Java' int' ... – Ivan
Int jest typu AnyVal, a typy wartości nie są null. – drexin
jak wspomina @oxbow_lakes, rzucanie jest lepsze niż zwracanie wartości zerowej w większości przypadków –