El chat java

Ola pues este es codigo de un chat con ayuda de un libro pero pues me marca erro en los list espero que me ayuden a descubrir cual es mi erroR
gracias!!!

import java.io.*;
import java.sql.*;
import java.util.*;
import java.text.*;
import java.lang.*;
import java.net.*;
import java.rmi.*;
import java.util.List.*;
import javax.swing.*;

public class ServidorCharla{

private static Lista listaCliente = new List();
//private static List Listacliente = new ArrayList();
private static int id = 0;

public static void main (String []args) throws IOException {
int puerto = 8190;
if(args.length > 0)
puerto = Integer.parseInt(args[0]);
ServerSocket oyente = new ServerSocket(puerto);
System.out.println(" El servidor charla se ejecuta en el puerto " + puerto);

while(true){
Socket cliente = oyente.accept();
new GestorCharla(cliente).start();
System.out.println("Nuevo cliente no."+id+" desde " +oyente.getInetAddress()+ "en el puerto "+cliente.getPort());
listaCliente.reponer();
listaCliente.agregar(cliente);
id++;
}
}

static synchronized void difundir(String mensaje,String nombre)

throws IOException {
Socket s;
PrintWriter p;
for(listaCliente.reponer(); !listaCliente.fin(); listaCliente.sucesor()) {
s = (Socket)listaCliente.actual();
p = new PrintWriter(s.getOutputStream(), true);
p.println(nombre+": "+mensaje);
}
}

static synchronized void eliminar(Socket s) {

Socket t;
for(listaCliente.reponer();!listaCliente.fin();listaCliente.sucesor()) {
t = (Socket)listaCliente.actual();
if(t.equals(s))
break;
}
listaCliente.borrar();
id--;
}
}
class GestorCharla extends Thread {

private BufferedReader entrada;
private PrintWriter salida;
private Socket paraCliente;
private String nombre;

GestorCharla (Socket s){
paraCliente = s;
}

public void run(){
try{
entrada = new BufferedReader(new InputStreamReader(paraCliente.getInputStream()));
salida = new PrintWriter(paraCliente.getOutputStream(), true);
salida.println("Bienvenido a la Charla");
salida.println("Escroba BYE para terminar");
salida.println("Como te llamas ?");
salida.flush();
String nombre = entrada.readLine();
ServidorCharla.difundir(nombre+"Se ha unido a la discusion","Charla");

while(true){
String s = entrada.readLine().trim();
if(s.length() > 2 && s.charAt(0) == 'B' && s.charAt(1) == 'Y' && s.charAt(2) == 'E'){
ServidorCharla.difundir(nombre+"Ha dejado la discusion","Charla");
break;
}
ServidorCharla.difundir(s, nombre);
}
ServidorCharla.eliminar(paraCliente);
paraCliente.close();
}
catch (Exception e){
System.out.println("Error en la charla: " + e);
}
}
}

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de skuarch

¿?

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 ?????

Imagen de skuarch

otra recomendacion

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

public void metodo1()  throws Exception{}

public void metodo2()  throws Exception{}

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:

public void metodo1()  throws Exception{
   try{

   }catch(Exception e){
      System.out.println("ERROR: metodo1() " +e);
   }
}

public void metodo2()  throws Exception{
   try{

   }catch(Exception e){
      System.out.println("ERROR: metodo2() " +e);
   }
}

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

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

Imagen de Jvan

Revisa el import

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

Imagen de ezamudio

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.

@payback

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> )

Imagen de skuarch

No concuerdo contigo

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

Imagen de ezamudio

Mala práctica

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 instanceof", 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:

try {
 //tu codigo aqui
} catch (NoSuchAlgorithmException ex) {
  //No existe el algoritmo de cifrado o digestion
} catch (GeneralSecurityException ex) {
  //Alguna otra bronca cifrando los datos o haciendo digestion; puede ser llave invalida, tamaño de bloque inadecuado, etc
} catch (IOException ex) {
  //Esta bronca no tiene que ver directamente con el cifrado o la digestión sino con lectura o escritura de datos en streams
}

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.

Imagen de bimboso_d

¿se puede?

Hola ezamudio, en el codigo que pones, ¿se puede poner?

try {
 //tu codigo aqui
} catch (NoSuchAlgorithmException ex) {
  //No existe el algoritmo de cifrado o digestion
} catch (GeneralSecurityException ex) {
  //Alguna otra bronca cifrando los datos o haciendo digestion; puede ser llave invalida, tamaño de bloque inadecuado, etc
} catch (IOException ex) {
  //Esta bronca no tiene que ver directamente con el cifrado o la digestión sino con lectura o escritura de datos en streams
}catch(Exception e){
  //Cualquier otro problema que se presente?
}

como cuando en PL/SQL tomas una excepcion y pones una general con when others
Saludos

Imagen de ezamudio

a ver otra vez...

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.

Imagen de bimboso_d

Hooo

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

Imagen de ezamudio

No

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 InputStream.read() throws IOException 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.

catch (Exception e) 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.