Error "class String Not Valid"

toro2186 · #1 25-07-2005

Hola señores , tengo la semana entera buscando informacion sobre el error "Class string not valid". Evidentemente que es una cadena de clase no valida pero busco informacion sobre eso y no encuentro. Soy nuevo en delphi y se que ahora entenderan porque lo digo .- Si alguien me puede ayudar lo agradeceria.

Gracias

dec · #2 26-07-2005

Hola,

He buscado en la ayuda de Delphi en general; por los mensajes de error del compilador; en Google por la cadena de error exacta y no aparece ningún resultado...

Si te encuentras con ese error al tratar de compilar, o, en todo caso, tal vez sería bien que refirieras aquí al menos la parte del código fuente (¿la línea/instrucción quizás?) en que obtienes el error.

ContraVeneno · #3 26-07-2005

Tambien podrías usar una instrucción mas o menos como sigue para tratar de definir de que tipo de error estamos hablando o poder tener un poco más de información respecto a este error:

Código Delphi [-]try
... //aquí la instrucción donde marque el error
except on E:Exception do begin
  showmessage('Clase: 'E.ClassName+' - Mensaje:'+E.Message);
  raise; //¿necesario?
 end; //Fin except
end; //Fin try

Aclaro que este código es solo para conocer más acerca del error que te marca;
de cualquier manera bienvenido al foro y no te olvides de leer la guía de estilo.

vtdeleon · #4 26-07-2005

Cita:

Empezado por ContraVeneno

Código Delphi [-]....
   raise; //¿necesario?
...

Ni Idea para que se usa. Vi un hilo que hicieron referencia sobre eso. No lo entendi

ContraVeneno · #5 26-07-2005

En muchos casos es necesario que coloques un raise para que cuando ocurra un error que no conoces o no esperas, sea mostrado... además porque este código captura cualquier error (E:Exception) cosa generalmente no debería suceder a menos que sepas exactamente que hacer.... bueno, en caso de que sea necesario, habrá que conocer sobre las excepciones, y habrá que revisar este hilo

en fin, la parte de "¿necesario?" es para este código en específico ya que en la parte del showmessage muestra la clase de error y el mensaje, cosa que tambien hace el raise, de ahí mi duda si era necesario en este código en específico.

dec · #6 26-07-2005

Hola,

Cita:

Empezado por Contraveneno

En muchos casos es necesario que coloques un raise para que cuando ocurra un error que no conoces o no esperas, sea mostrado (...)

Raise eleva, como suele decirse, la excepción que se produzca.

Cita:

Empezado por Contraveneno

en fin, la parte de "¿necesario?" es para este código en específico ya que en la parte del showmessage muestra la clase de error y el mensaje, cosa que tambien hace el raise (...)

No, exactamente. Obsérvese/pruébese el siguiente código:

Código Delphi [-]    procedure TForm1.Button1Click(Sender: TObject);
    begin
      try
        Pruebas;
      except
        ShowMessage('Estamos en Button1Click');
      end;
    end;
    
    procedure TForm1.Pruebas;
    var
      i,j: integer;
    begin
      i := 0; j := 0;
      try
        i := i div j;
      except
        ShowMessage('Estamos en Pruebas()');
        Raise;
      end;
      // Usamos la variable "i"
      Caption := IntToStr(i);
    end;

En este caso se producirá una excepción "EDivByZero" y se mostrará el mensaje "Estamos en Pruebas()", pero, puesto que "elevamos" la excepción mediante Raise y además hemos incluido la llamada al procedimiento "Pruebas" en un bloque "try .. except" también podremos ver el mensaje "Estamos en Button1Click".

Si no hubiéramos llamado al procedimiento "Pruebas()" en un bloque "try .. except" pero hubiéramos "elevado" la excepción, en este caso, la excepción seguiría hacia arriba hasta ser tratada por el método oportuno de la clase "TApplication" y veríamos el mensaje "Error: EDivByZero exception", luego de "Estamos en Pruebas()".

Si no incluyéramos la instrucción Raise se mostraría el mensaje "Estamos en Pruebas()" y ninguno otro, puesto que ese es el tratamiento, en este caso de ejemplo, que dimos a la excepción y no quisimos ir más allá elevando la excepción para que la rutina que llamara a la que la produjo pudiera tratarla por su parte.

Si añadiéramos una instrucción Raise dentro del bloque "try .. except" del evento "Button1Click" entonces podríamos ver tres mensajes, en este caso: el "Estamos en Pruebas()", el "Estamos en Button1Click" y por último, insisto, en este caso, el mensaje "Error EDivByZero" exception".

vtdeleon · #7 26-07-2005

Saludos

Dec Gracias, Me quedo mas claro que el Aire(Oxigeno)

Segun entendi: si realizamos la division entre zero, el sistema mostrara una excepcion diciendo que no se puede dividir entre 0...blabla, por lo que muchos de nosotros (no me escapo de esta:P) nos gusta personalizar esta excepcion con un mensaje o un PLAN B.
Al Añadir Raise muestra el mensaje personalizado y tambien el del sistema.

Espero que esto halla sido asi. Hice unas pruebas con el codigo ofrecido por Dec y prueba lo que escribo

dec · #8 26-07-2005

Hola,

Cita:

Empezado por vtdeleon

Segun entendi: si realizamos la division entre zero, el sistema mostrara una excepcion diciendo que no se puede dividir entre 0... (...)

Mostrará un mensaje, no una excepción: la excepción podríamos decir es un estado "interno" del programa que el usuario no verá nunca, porque en realidad no puede verse cómo se ejecuta el programa y en qué estado se encuentra: lo que mostramos al usuario es un mensaje, que, efectivamente, corresponde, de algún modo, a la excepción que se esté tratando, informa de ella, pero podría no mostrarse ningún mensaje al usuario y la excepción seguir ahí...

Bueno. Cuando se produce una excepción dentro de una rutina "A" y en esta no se da un tratamiento a dicha excepción (no hay un bloque "try .. except" en ella) la excepción se "pasa" a la rutina que llamó a la rutina "A".

Es una cadena: que llegará a la primera rutina de todas, de la clase "Application", si no estoy equivocado (por favor, háganmelo saber si es así) la cual tratará la excepción, bien mostrando un mensaje, bien acabando con la ejecución del programa si no es posible continuar con su ejecución "normalmente".

Esto creo que tiene que ver con los dos posibles estados que puede haber en un programa dado: el estado "normal" y el estado de "excepción". En un estado de "excepción" alguien (alguna rutina) habrá de encargarse de dicha excepción de todas, todas. Así se garantiza que una determinada excepción sea tratada incluso si nosotros no lo hacemos.

Cita:

Empezado por vtdeleon

... por lo que muchos de nosotros (no me escapo de esta:P) nos gusta personalizar esta excepcion con un mensaje o un PLAN B. (...)

Y ya no que nos guste, pero, podemos evitar un estado de "excepción" que pueda echar abajo a nuestro programa o sencilamente, después de probar con un "plan A", si este no va como se espera, probar con otro "plan B", a ver si tenemos algo de más fortuna. Imagina un "plan B" para la excepción de más arriba (EDivByZero) siempre que este fuera posible, quiere decirse que trataríamos primero de llevar a cabo la división ("plan A"), pero, si surgiera algún problema, todavía no nos quedaríamos con los brazos cruzados y trataríamos de dar una solución a esto mediante un "plan B".

Dado que se descubre que la excepción es la que es, y que dividir por cero no tiene mucho sentido, podríamos incrementar la variable "con valor 0" de tal modo que la división fuera posible, con lo que conseguiríamos ofrecer un resultado coherente y que nuestro programa siguiera funcionando, ya con este otro resultado y fuera del estado de excepción, informando o no al usuario según lo consideremos menester.

De todas maneras vtdeleon es probable que mis conceptos no estén del todo claros y así no los pueda transmitir correcta ni acertadamente, por lo que te pido tomes lo que digo con pinzas y no dejes de informarte por otros medios respecto de lo que nos ocupa. Este es un buen lugar, puesto que se pueden cruzar ideas, opiniones, teorías, en fin, para bien de todos nosotros, para aprender, en definitiva.

vtdeleon · #9 26-07-2005

Saludos

De todos modos Gracias Dec. Soy pesimo conceptualizando y expresando algunas ideas pero me queda claro lo que me has dicho:P Grax

ContraVeneno · #10 26-07-2005

por eso dije "en este código en específico" donde las siguientes dos instrucciones:
showmessage('Clase: 'E.ClassName+' - Mensaje:'+E.Message);
raise; //¿necesario?
sirven para prácticamente lo mismo.

de hecho, realmente creo que una secuencia

Código Delphi [-]try
...
except
showmessage('mi error');
end;

no debería usarse de esa manera. Para evitar esto, estan las clases de error (EDivByZero, EDBEngineError, EConvertError, etc, etc, etc). En este caso en específico la propuse para conocer la clase de error que marca. Esto solo que sea en tiempo de ejecución, ya que si es en tiempo de diseño habría que hacer otra cosa.

En fin, yo sigo esperando a que Toro2186 no cuente que ha pasado con su problema.