LonelySoulGamer escribió:DaNyPoNs8 escribió:Gracias por hacernos ver qué la basura que nos ha enseñado Héctor, en realidad lleva más basura interna oculta que disimula que no salga más mierda a la luz.
Vaya mierda de juego.
No no es así para nada. Las excepciones son algo total y completamente imprescindible en cualquier programa. No es basura interna dentro del código para disimular nada.
VengerDD escribió:Se ve que no sabes de programación, al igual que todos los que dicen que el juego no crashea o que no peta. El juego SÍ crashea y SÍ se peta, lo que pasa que ahora habrá implementado excepciones al código de las funciones (a saber si en todas o solo en algunas de ellas) o habrá pedido en el código al propio Sistema que se encargue de ellas, y eso hace que no salga ninguna pantalla de error como las que salían antes y que hacía que el juego se cerrase. Pero ¿tu has visto que en el juego hay partes en donde no responde como por ejemplo cuando se intenta cargar partida, o cuando intenta construir algo en la ciudad y no pasa nada, o cuando guarda o carga la ciudad deportiva y se queda bloqueado al 99%, o cuando tienes que pulsar varias veces en una opción y no ocurre lo que tiene que ocurrir y el juego no hace nada ni reacciona con ningún tipo de mensaje o icono de que esté procesando algo?. Todo eso son excepciones controladas y déjame decirte que por mucho que se controlen está bien porque el juego no se cierra, pero ¿de qué sirve si el juego a partir de ahí ya no va a poder continuar funcionando correctamente?.
Manejo de excepcionesLo dicho, dejad de desinformar los que no sabéis de programación porque así le hacéis un favor al desarrollador y a los que creen que todavía esto tiene solución porque son fallitos de nada.
No voy a defender a este individuo porque me la suda, ni me se lo merece. Pero el tema programación si me interesa. No quiero ser mal pensado, pero dices que no desinformen y tu desinformas al personal, ya tienes a uno que ha picado en lo que has soltado(arriba tienes la cita). NO sé, algo me falla en esto o no lo he entendido bien o no te has explicado bien o algo de ambas. Quiero que nos expliques a los que si sabemos de programación, como tratas tu las excepciones en eso que tu llamas funciones pero que son métodos porque C# esta orientado a objetos y dentro de las clases como sabrás no se llaman funciones sino métodos. (Ya que hablas habla con propiedad).
Quiero saber que propones tu hacer con una operacion de I/O sin esas "excepciones" que dices que "si petan y crashean" el sistema cuando estan tratadas. Iluminanos a los que sabemos de programación que haces tu con las excepciones cuando accedes a la base de datos del juego. Por poner un ejemplo. Me genera mucha curiosidad, porque hablas de ellas como si fuesen un puto demonio que esconde maldades, cuando cualquiera que sepa algo de programación sabe que son imprescindibles en un programa medianamente complejo.
Creo que al menos estaremos de acuerdo en que una excepcion trata un error que evita la finalización prematura del codigo que se esta ejecutando (dicho de otro modo programa). No voy a entrar en detalles de Excepciones en tiempo de ejecución, Controladas y del sistema porque no viene a cuento ni vamos a extendernos. Asi que me choca que dijas que tratando las excepciones "si que petan y si que crashean" los procesos (Hilos o lo que lo ejecute). No sé explicanos a los que si sabemos de programación que cojones quieres decir con eso.
Porque da la impresión de que hablas del tratamiento de excepciones como si fuese una puta lacra que ralentiza el programa. Cuando eso no es así. No es el tratamiento de excepciones lo que ralentiza nada (como mucho hace lo opuesto a lo que dices) evitar que reviente el proceso (o hilo) que ejecute ese código.
Lo que ralentizará el proceso es la pésima implementación del código hace de estas operaciones bloqueates (como acceso a base de datos o I/O), no las excepciones que hay que implementar por cojones en todas esas operaciones de las que hablas. Una carga de un fichero implica una excepcion de I/O (Input/Ouput) (entrada/salida) que hay que tratar si o si siempre en todo lenguaje de programación. Porque si falla el acceso al recurso es normal que el proceso termine prematuramente con un error no controlado.
Porque como sabrás una operacion de ese tipo (i/O) es bloqueante, lo que hace que la cpu tienda a dar prioridad a otro hilo (o proceso) mientras esta ejecutando el código. Asi que de por sí es normal que se ralentice el juego. De ahí que la gente que hace videojuegos con buenas prácticas de UI /UX ponga pantallas con esa informacion (barras de carga, etc) que informan al usuario. (No me extraña que alguien centrado en back-end como H.P: obvie este tipo de cosas... pero eso es otro tema).
No voy a entrar en si el código es una mierda o no, porque no puedo leerlo (aunque me encantaría). Pero como cualquier programador sabe no es problema de las excepciones que pueda tardar más o menos en ejecutarse, sino de una pésima implementación en código de los procesos de I/O o acceso a base de datos. Eso sin obvíar que de por sí ya son operaciones bloqueantes, que como bien dices requeire de informar al usuario. Y como se hace en muchos juegos informar mendiante una pantalla de carga con su barra, un loader o lo que sea (si quieres hacer buenas prácticas de UI/UX). El acceso a bases de datos puede, en determinados contextos, puede hacerse con una carga previa que puede requerir de algun hilo en parallelo (por uno de los multiples sistemas de concurrencia que hay) que a su vez pueden requerir de excepciones. No culpemos a las excepciones del codigo que haga esta gente, que no tienen culpa de nada y son total y completamente imprescindibles en un programa de estas caracteristicas. De hecho si cometió un error fue no haberlas implementado en su momento, en vez de a posteriori. Esa sería la chapuza, no el tratar las excepciones. ¡¡¡Que manda huevos tener que explicar esto!!!