Should I allow a plugin to crash my application?_问答_开发者

I am adding an event driven plugin api to a web based system I am working on.

Should I wrap the plugin calls in a try/catch to make sure they don't crash or should I leave this up to plugin developers to take care of.

Also, some of the plugins may change the data I pass them, should I re-validate all the data or 开发者_运维知识库trust the plugin developers not to break anything?

You should not let your program crash.

If you can protect yourself from innocent mistakes by plug-in writers, you should do so - both by handling exceptions and by revalidating modified data that your code must reuse.

What you do when you find a problem (exception or malformed data) is up to you - unloading the plug-in and not using it again until it is reloaded might be sensible in production mode. For plug-in developers, providing good diagnostics of what went wrong would be sensible - possibly even crucial to gaining widespread acceptance (lots of people writing plug-ins for you). If the other programmers cannot resolve problems effectively, they may not continue to try.

Should windows crash in case a third party app crashes or should it incorporate some kind of process isolation?

Should firefox crash if a plugin crashes?

There's your answer. Never trust 3rd party to to their job as they should.

There is a nice addition to Firefox, which prevents a plugin to crash the main application (e.g. Flash).

The main application must always have control. As the name implies a plugin is one among others and should not be able to stop the main + other plugins. Also, by keeping control over plugins, the main application may still provide directions to the user to either

uninstall the plugin
look for an alternative etc...

Keeping control allows the user to be aware of what is happening and who is responsible.
In Firefox I like that I'm able to know who made an attempt (kind of) to crash the application.

This way you as the main application developer, you are not criticized for a bad job you didn't do in the first place.

As for control of data

It depends on the application and the kind of data. If the data has an impact over the other plugins and the main application itself, it should be controlled, adjusted or fixed.

As an analogy .. would you accept any user data without validating it?

In this case I see try/catch as the program execution analog of user validation

When we write standalone program and prevent it from crash by using some kind of global try-catch, we successfully hide a bug details, preventing these bugs to be fixed. Generally, unexpected unhandled exception should crash the program. This is the way to debug such exception just when it is thrown, or generate crash dump for post-mortem debugging.

Program which loads third-party plugins, obviously, must be protected from plugin crash. On the other side, it is a good idea to give chance to plugin developers to fix their bugs, allowing the whole program to crash. I would consider to add some special running mode to such program, this can help to plugin developers. Of course, such mode should not be available for normal users. In the normal mode I would catch all plugin bugs, preventing the hosting program to crash, but every plugin crash should be logged with maximum possible details.

There isn't really a language-agnostic answer to this question, but I'll assume that the plugin is some kind of dll.

If you can avoid trusting the plugin, there are some potential benefits from avoiding it. If nothing else it helps isolate bugs, but also it provides your user with some protection from malicious plugins, and helps with the reliability and robustness of your app.

However, it is fairly difficult to avoid trusting a plugin. Depending on OS, are you going to run it in its own process with minimal privileges, no filesystem or sockets access, restricted access to resources such as memory and CPU time, a monitor that will kill it if it appears unresponsive, communicating with your process only through a pipe? If not, then some buggy plugin will find a way to ruin your afternoon, meaning that you've "relied on" its correctness whether you intended to or not.

Catching exceptions implies that you're running the plugin in one of your application threads. So you are trusting it. You can't "make sure it doesn't crash" if it has the ability to do some OS-specific thing that will make the kernel shut down your process with extreme prejudice.

All that said - on the specific issue of catching exceptions, callers should catch exceptions if and only if they can do something useful with them.

I'd catch them if the plugin is doing something non-essential (e.g. rendering one component of a web page), or let them go if the plugin is doing something absolutely essential to the program (for example if it's a video codec in a command-line transcoding program, maybe I'd catch the exception and rethrow it after logging an error "blaming" the fault on the plugin. Otherwise I'd handle it the same as any other unexpected error in the program).