#3361 Vale, ya veo.
Estoy de acuerdo en que si vas añadiendo excepciones conforme tu codebase crece tienes un problema de diseño bastante serio y que al final todos los métodos tienen siete throws y cuatro try-catch anidados y meter mano ahí es una mierda como una casa.
No, because in a lot of cases, people don't care. They're not going to handle any of these exceptions. There's a bottom level exception handler around their message loop. That handler is just going to bring up a dialog that says what went wrong and continue. The programmers protect their code by writing try finally's everywhere, so they'll back out correctly if an exception occurs, but they're not actually interested in handling the exceptions.
Esto es una verdad como una casa, pero no es que a la gente no le importe, es que las empresas no te pagan para hacer eso. Si le dices a tu jefe que necesitas un día para refactorizar un código como ese, que barre y tira la mierda en un finally, te va a decir que verdes las han segado y que te pongas con algo que genere beneficio. Luego que si deuda técnica y que si el código es una porquería, claro.
The scalability issue is somewhat related to the versionability issue. In the small, checked exceptions are very enticing. With a little example, you can show that you've actually checked that you caught the FileNotFoundException, and isn't that great? Well, that's fine when you're just calling one API. The trouble begins when you start building big systems where you're talking to four or five different subsystems. Each subsystem throws four to ten exceptions. Now, each time you walk up the ladder of aggregation, you have this exponential hierarchy below you of exceptions you have to deal with. You end up having to declare 40 exceptions that you might throw. And once you aggregate that with another subsystem you've got 80 exceptions in your throws clause. It just balloons out of control.
Y esto es otra verdad como un templo, pero es más otro problema de diseño que del manejo de excepciones. Estoy de acuerdo en que tal y como está hecho te permite olvidarte de las excepciones, no tratarlas y simplemente evitar que todo explote, pero es un poco como los null check: si te puede llegar un atributo a null pues vale, pero si de un DAO te pueden llegar el 60% a null no es viable hacer null checks de todo, ahí hay un tema de diseño que se debería pensar un poco más y no modelar a piñón y luego ya iremos viendo.
