El chat java

Pero que excepcion te envia ????? si pudieras poner el printStackTrace() pues igual y seria mejor !!!!, la excepcion es con el cliente o con el servidor ?????

cuando utilizas throws Exception al inicio del metodo, hay ocaciones que no se tiene con certeza que metodo lanzo la excepcion por ejemplo

y la excepcion dice: javaLangNullPointerException

¿entonces que metodo la lanzo, el 1 o el 2?

en ocaciones se tiene que hacer mas codigo pero podria ayudarte a resolver mejor los problemas, por ejemplo:

entonces el error diria ERROR: metodo1() javaLangNullPointerException. Asi seria mas facil encontrar el error

Tambien te puedes apoyar de algun jar para el manejo de logs por ejemplo apache log4j

que onda borther me manda
este error cuando lo compilo en el cmd

cannon file symbol
simbol List

no funciona por que me manda ese error XD

Revisa el import   segun yo deberías de quitarle el .* del final a ese import.

Ya tiene import java.util.* así que no se necesita import java.util.List.*

Cachar Exception es muy mala práctica. Debes cachar solamente las excepciones que vas a manejar en ese punto y las que no las dejas pasar, si son declaradas las declaras en el método que contiene el código que las arroja.

Revisa bien el mensaje de error. Solo es cosa de que te lo expliquen una vez y podrás entender lo que dice las siguientes veces.

El mensaje de error te digo que es lo que no ecuentra y en que número de línea está ( si tuvieras varios archivos te dice también en cual de ellos está el error )

Vuelve a compilar e incluye tu mensaje de error ( y por todo entre <code> y </code> )

que onda zamudio, a poco cachar Exception es mala practica, como que no concuerdo contigo, bueno eso depende de como la manejes si solo la imprimes la exception es equivalente a un throws Exception al inicio del metodo, pero si le anexas algo de informacion yo creo que es mejor.

Pero si estoy deacuerdo en que se deben de tratar diferente algunas Exceptions

Cachar Exception (la clase java.lang.Exception) es mala práctica porque es demasiado general. Siempre debes cachar la excepción más específica posible, o si hay varias que se pueden arrojar y tienen una superclase en común entonces cachas esa.

Por ejemplo, si estás generando un Cipher y un MessageDigest y luego los inicializas para cifrar datos con una llave y luego hacer una digestión, hay varias excepciones que se arrojan, pero si no quieres meterte mucho a detalle entonces solamente cachas GeneralSecurityException, que es la superclase de InvalidKeySizeException, AlgorithmNotFoundException, etc. Si los datos que estoy leyendo vienen de un stream, entonces seguramente por ahí debo cachar una IOException, que nada tiene que ver con las excepciones de seguridad. Si cacho GeneralSecurityException y además IOException, cada error lo debo manejar de manera distinta; incluso si es solamente presentar un error al usuario, será un error muy distinto; no es lo mismo decir "No puedo encontrar el algoritmo AES o MD5" que decir "Hubo un error leyendo los datos que hay que cifrar" (si sé que vienen de un socket puedo incluso decir "Hubo un error leyendo los datos de la red" o algo así).
Si solamente cacho Exception, entonces al entrar a ese bloque no sé si ocurrió GeneralSecurityException, o IOException, o NullPointerException, o IllegalStateException, o alguna otra subclase de RuntimeException... y antes que alguien diga "ah pues le pones un  ", precisamente para eso es que puedes poner varios catch dentro del mismo try, siempre primero las excepciones más específicas y luego las más generales, por ejemplo:

Si ocurre una NPE que no debía ocurrir pues ya se irá hasta la consola y se interrumpe la ejecución del programa y ves el stack trace y te das cuenta que es un error de programación porque le estás pasando un parámetro nulo a un método que esperaba recibir un objeto, y entonces ya corriges ese problema en tu código y lo vuelves a correr y ya no volverás a obtener NPE en ese punto porque no debe ocurrir.

Hola ezamudio, en el codigo que pones, ¿se puede poner?  
como cuando en PL/SQL tomas una excepcion y pones una general con when others
Saludos

Cachar Exception (la clase java.lang.Exception) es mala práctica porque es demasiado general.

Habiendo dicho eso... sí, técnicamente, puedes hacer lo que dices, cachar Exception hasta el final. Para qué quieres cachar Exception hasta el final? Por qué quieres cachar absolutamente cualquier excepción? Las vas a poder manejar absolutamente todas? Cuando cachas Exception, no solamente son todas las excepciones declaradas, sino también todas las de tiempo de ejecución (subclases de RuntimeException).

Si no es pertinente manejar una excepción, no la caches. Solamente debes cachar las excepciones que es pertinente manejar en tu código. Si el código de un método arroja alguna excepción declarada y NO es pertinente manejarla en el código de tu método, entonces la declaras en tu método en vez de cacharla. Si sabes que puede ocurrir alguna excepción de tiempo de ejecución y es pertinente manejarla, entonces la cachas en donde puede ocurrir; si no es pertinente manejarla, no la caches; y como no es declarada, no tienes que declararla si no quieres.

Cachar Exception simplemente para presentar un diálogo de error al usuario puede ser peor que no cachar la excepción porque les dificulta la depuración de su aplicación, incluso cuando la están desarrollando. Y si no dejan un log con el stack trace completo, nunca sabrán bien qué pasó, en dónde se arrojó la excepción, por qué ocurrió, etc.

Entonces Catch(Exception e) tambien cacha las ya declaradas umm weno ya mas o menos tengo la idea y si era la intencion obtener cualquier otra excepcion, pero como dices si no se cual es, mucho menos como manejarla jajaja ok ok
Gracias

Hay dos tipos de excepciones: excepciones declaradas (Exception y todas sus subclases) y excepciones de tiempo de ejecución (RuntimeException y todas sus subclases, junto con Error y todas sus subclases).

Una excepción declarada es la que está en la declaración de un método, por ejemplo si ves un método como   ahí se declara que el método read() de la clase InputStream arroja IOException, y por lo tanto cuando llamadas ese método, tienes que haces una de dos cosas: llamar el método en un bloque try-catch para cachar esa IOException, o declarar que el método desde donde llamas a read() arroja IOException. Cuál debes usar? pues depende de cada caso. Si vas a manejar el IOException y puedes convertirlo en otra cosa (arrojar una excepción distinta cuya causa original sea la IOException) o presentar un error al usuario, cerrar el stream/socket/loquesea e informar a quien invoca tu método que la operación falló (o reintentar o lo que sea), entonces está bien cacharla. Si de plano es algo que no debería manejarse en tu método entonces declaras la IOException en tu método y será bronca de quien llame tu método, declarar IOException o cacharla.

  va a interceptar todas las excepciones, declaras y de tiempo de ejecución. Y la neta no creo que vayas a manejar todas las excepciones posibles en un catch, y no debes cachar excepciones que no vas realmente a manejar, por lo que no debes cachar Exception (a menos que no tengas de otra porque a alguien que no sabe programar se le ocurrió declarar un método que arroja Exception).

Creo que la intención era buena pero el forzar el try-catch o declarar la excepción con subclases de Exception ha sido muy mal entendido por muchos programadores y por eso vemos tantos bloques de try-gulp (o sea un try-catch con el catch completamente vacío) que luego causan muchos problemas porque es muy difícil depurar una aplicación que tiene cosas así. Por qué? Pues porque no se arroja la excepción, porque el código se la traga enterita y sigue ejecutando.

En .NET por ejemplo todas las excepciones son de tiempo de ejecución, de modo que no estás obligado a cachar ninguna excepción. En Groovy también cualquier excepción se vuelve de tiempo de ejecución, nunca estás obligado a poner un catch. Eso trae sus propios problemas, distintos, pero trae problemas. Por eso es difícil programar bien.