Se puede evitar los mensajes de error
 

Sino quiero que cuando ejecuto el programa me salgan mensajes de error en inglés , sin necesidad de poner excepciones en todos los sitios , hay alguna manera de evitar estos mensajes , que no salgan de ninguna de las maneras .

Lo digo para Delphi 5.

Aqui tienes algo para divertirte:
http://www.clubdelphi.com/foros/showthread.php?t=10402

Saludos!

También puedes hacer:

Código Delphi [-]
PROGRAM programa;

USES
   blah, bla...

.
.
.

BEGIN
  TRY
    { Aquí el código de la aplicación. }
   .
   .
   .
  EXCEPT
     { No hacer nada }
  END;
END.

Et voilá! Si ejecutas dentro del IDE seguirán apareciendo las excepciones, pero si ejecutas fuera de él no saldrá mensaje alguno: el programa terminará sin dar explicaciones de nada.

Hola,

No sé yo si capturar excepciones para luego no hacer nada con ellas (esto es, para ocultar errores) es una buena idea. Diría que no, pero, en fin, nunca se sabe. ;)

Respecto de que siempre aparecerán las excepciones mientras estemos en el IDE, lo cierto es que hay una opción en Delphi para que incluso en el IDE las excepciones no "nos molesten", si queremos:

Código Delphi [-]
procedure TForm1.Button1Click(Sender: TObject);
var
  a, b, c: integer;
begin
  a := 0;
  b := 10;

  try
    c := b div a;
  except
    // No hacemos nada...
  end;

  // ¿Qué diablos valdrá "c"?
  ShowMessage(IntToStr(c));
end;

Bueno, yo no dije que fuera buena idea.

De todas formas, ahora que caigo (debí leerlo mejor la primera vez :rolleyes:) lo que creo quiere nuestro amigo David es que no salgan los mensajes en Inglés. Creo que hay por ahí una herramienta o paquete que permite traducir los mensajes internos de Delphi. El problema es que no tengo Delphi instalado así que, si alguien sabe cómo traducir los mensajes internos, agradeceré(mos) que lo explique.

Si no quieres ver mensajes en inglés en tus aplicaciones, sólo hay una solución viable, Debuguear en tiempo de ejecución es necesario la JCL (como mínimo)

Hay otras soluciones, como han dicho de ocultarlas. Si quieres ser "un chapucero", hazlo; no lo digo con desdén, es que simplemente jamás te vas a enterar que tu programa da errores, y jamás podrás quitar esos errores; simplemente el programa no hace lo que se espera, pero no sabes por donde estará el fallo.

La solución óptima es tener en cuenta que pueden ocurrir errores, controlar por código aquellos más obvios ( "aaa" is not a valid integer) y el resto de errores, dejar que lleguen al evento Application.OnException, allí muestras un mensaje en español indicando que se ha producido un error, si procede, muestra el código de error para que el cliente te lo diga por teléfono.

En ese mismo evento usa la variable lpjcldebug.Error para escribirla en un archivo de texto:
- El código de error producido
- La linea del código fuente donde se ha producido
- La excepción en inglés de la VCL de Delphi.

Saludos

El caso es que yo le presento al cliente , el programa sin mensajes de error en inglés , el programa que tengo yo , si que permito que salgan errores para tratar de corregirlos , pero cuando decirlo entregarlo al cliente , pues quiero que no haya vuelta de hoja y no salga algo en inglés y si falla algo , pues hacerle ver que cambiar eso seria una mejora del mismo , con sus contraprestaciones .

Reitero lo dicho, y amplío un poco más.

Si el programa está muy verde, porque te han metido mucha prisa, porque has usado módulos que no estan testeados al 100 %, etc, deriva los mensajes de error al .Log y no muestres nada al usuario. En este caso, pásate una vez por semana alegando que tienes una versión mejorada, que tal o cual componente que usas en tu programa han sacado una versión nueva y has tenido que actualizarlo, etc.

Si te vé mirando el archivo de errores, no se lo ocultes, busca algún error trivial como "aa is not a valid integer", "22/ /05 is not a valid date", etc, y explicale al cliente que con ese archivo ves la forma en que usa tu programa y así lo puedes adaptar a su forma de trabajar y a sus necesidades, ya que tú no estas delante del ordenador cuando él lo usa.

Yo por ejemplo tengo varios tipos de excepciones en mis programas:

Código Delphi [-]
type
  EControlada = class(Exception);
  EFacturacion = Class (Exception);

Todo fallo del tipo "aa is not a valid date", lo puedo ocultar y mostrar al usuario un BalloonHint de esos bien bonitos diciéndole que la fecha no es válida. Cuando salta una excepción, primero capturo la excepción de Delphi, la sustituyo por la mia y despues en el ApplicationsEvents la oculto o no dependiendo de la categoría (controlada, facturacion, etc).

Código Delphi [-]
try
  TheDate := Strtodate(Edit1.text);
except
  raise EControlada.CreateFmt('Error la fecha  %s no es válida', [Edit1.text]);
end;

Si el fallo se produce al facturar, pues eso no lo dejo pasar, directamente se lo muestro al usuario.

Código Delphi [-]
  raise EFacturacion.Create('error al crear la factura ....');

En el applicationEvents puedo obviarlas según la categoria de la excepción:

Código Delphi [-]
procedure TFrmMain.ApplicationsEventsException(E:Exception; var Cancel:Boolean);
begin
  LogWrite(E.Message);
  if e is Econtrolada then
     Cancel := true; // esto es de las LMDTOOLS

  if e is EFacturacion then
   raise; // la muestro al usuario

Bueno... esto más o menos, ya que uso otros componentes más, en concreto las LMDTOOLS 6.0 SE que traen un componente TApplicationsEvents que puede ocultar las excepciones, (no sé si la JVCL trae algo parecido).

Saludos

Saludos

Espera tantito, Seguro qeu Delphino contestará eso:D:D