Delphi AV 与 Try-Except

发布于 2024-11-09 09:00:42 字数 632 浏览 0 评论 0原文

再会!

我有一个带有任务管理器的多线程应用程序,工作人员......我有一个问题。

线程执行方法看起来像:

try
 task.execute();
except
 on E : Exception do
 begin
   log(e.message);
   //  callResetThread/disconnectUser
 end;
end;

每个任务都有许多访问冲突、运行时错误...尝试-除了某些情况下不会 帮助。有没有任何解决方案可以保护我的程序免受线程错误的影响...

Delphi 7/没有jedi/默认内存管理器

更新

亲爱的朋友们! 我们的代码包含许多第三方组件。该程序在单用户模式下每周引发 1-2 次异常。当我们修改此程序以在服务器模式下工作并具有同等 500 个客户端时,我们可以有 > 每天 70 个异常(1-2 个可能是关键且未捕获的 try ... except ...end)。 我们确实明白我们必须修复所有错误:-)。但源代码(带有第三方组件)的大小> 20MB... 我们确实需要您的帮助,我们如何捕获此系统错误(可能是使用系统方法)。

Good day!

I have a multi-threads application with TaskManager, workers... And i have a problem.

threads execute-method looks like:

try
 task.execute();
except
 on E : Exception do
 begin
   log(e.message);
   //  callResetThread/disconnectUser
 end;
end;

Each task have many Access Violations, runtime errors... Try-except for some cases does not
help. Is there any solution for protect my program from the errors at threads...

Delphi 7/ no jedi/ default memory-managers

UPDATE

Dear friends!
We have a code with many third-party components. This program raised 1-2 exception per week in single user mode. When we modify this program to work in server-mode with equal 500 clients we can have > 70 exceptions per day (1-2 may be critical and not catched try ... except ...end).
We realy understand that we must fix all bugs :-). But source code (with third-party components) has size > 20 Mb...
We realy need your help, HOW WE CAN CATCH THIS SYSTEM ERRORS (may be with using system methods).

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

趁微风不噪 2024-11-16 09:00:42

Try- except 不应该“帮助”解决运行时错误。 应该通过修复程序中的错误来提供帮助,以便从一开始就不会发生访问冲突和其他错误。

如果发生异常并且您不知道原因,那么您无法在程序中执行任何操作来解决问题,因此您的程序没有理由继续运行。据您所知,您的程序的内存已经损坏,因此您能做的最安全的事情就是终止该程序,以免您的客户数据面临更多危险。

如果 try-except 块没有捕获异常,则要么您的程序已损坏,以至于您覆盖了程序中处理异常的部分,要么异常发生在 try- except 之外堵塞。

您可以尝试使用异常日志记录库,例如 MadExcept、EurekaLog 或 JclDebug。它们检测程序中的异常并记录信息以帮助您调试问题。

另一种可能性是,调试器在发生异常时中断您的程序并向您显示有关该异常的消息。那是调试器,而不是您的程序,因此如果您让程序继续运行,您将看到异常处理代码接管。

Try-except isn't supposed to "help" with runtime errors. You're supposed to help by fixing the bugs in your program so that the access violations and other errors don't occur in the first place.

If an exception occurs and you don't know why, then there's nothing you can do in your program to fix the problem, so there's no reason for your program to continue running. For all you know, your program's memory is already corrupted, so the safest thing you can do is to terminate the program so as not put your customers' data in any more danger.

If a try-except block isn't catching exceptions, then either your program is so broken that you've overwritten the part of your program that handles exceptions, or the exceptions are occurring outside the try-except block.

You can try using an exception-logging library such as MadExcept, EurekaLog, or JclDebug. They detect exceptions in your program and record information to help you debug the problems.

Another possibility is that the debugger is interrupting your program when an exception occurs and showing you a message about it. That's the debugger, not your program, so if you then let your program keep running, you'll see your exception-handling code take over.

遇到 2024-11-16 09:00:42

必须修复它们全部,真的!反病毒不仅是异常的问题,也是异常处理的问题。每个异常(AV)都会使您的程序或多或少陷入某种“未定义”状态,因为您的代码尝试将一些数据写入内存或从内存中读取一些数据,但这些数据无效。所以你的应用程序的结果或者它应该做的事情不起作用!而且不存在“不可能”!这是肯定可能的,否则你必须重写代码......

You HAVE to fix them ALL, really! The AV is not only a problem of the exception an the handling of it. Every exception (AV) throws you programm into some more or less "undefined" state, because your code tried to write or read some data into/from memory and the data is not valid. So the result of your App or the thing it is supposed to do is not working! And there is no "it is not possible"! It is for sure possible or you have to rewrite the code...

々眼睛长脚气 2024-11-16 09:00:42

获得比 try/except 更高的弹性的唯一方法是使用单独的进程(然后是单独的机器,然后是单独的数据中心等)。

听起来您使用的代码并非设计用于线程,更不用说您将在服务器应用程序中看到的繁重的多线程。我认为你目前的方法行不通。

The only way for you to get higher resilience than try/except is to use separate processes (and after that, separate machines, then separate datacentres, etc.).

It sounds like the code you are using was not designed to be used with threads, never mind the heavy multi-threading that you'll see in a server application. I don't think your current approach is workable.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文