RESOLVED FIXED 22310
Worker exceptions should be printed to console
https://bugs.webkit.org/show_bug.cgi?id=22310
Summary Worker exceptions should be printed to console
Alexey Proskuryakov
Reported 2008-11-17 07:59:38 PST
Firefox forwards uncaught worker exceptions to worker.onerror. I'm not sure if this behavior is desirable - for one, the current spec says that this event is just for loading errors. But we certainly should print them to console.
Attachments
proposed patch (12.12 KB, patch)
2008-11-17 08:22 PST, Alexey Proskuryakov
no flags
updated patch (23.47 KB, patch)
2008-11-17 11:06 PST, Alexey Proskuryakov
darin: review+
Alexey Proskuryakov
Comment 1 2008-11-17 08:22:42 PST
Created attachment 25215 [details] proposed patch
Darin Adler
Comment 2 2008-11-17 09:14:18 PST
Comment on attachment 25215 [details] proposed patch > + UString errorMessage = exception->toString(exec); > + JSObject* exceptionObject = exception->toObject(exec); > + int lineNumber = exceptionObject->get(exec, Identifier(exec, "line"))->toInt32(exec); > + UString exceptionSourceURL = exceptionObject->get(exec, Identifier(exec, "sourceURL"))->toString(exec); > + > + scriptExecutionContext->reportException(errorMessage, lineNumber, exceptionSourceURL); This seems like too much code to have here in line. I'd like to see a helper function that does more of this work. > + if (exec->hadException()) > + exec->clearException(); This if seems unnecessary. There's no reason to check for null before setting the value to null. Also, I think it's OK for new code to get and clear exceptions in the JSGlobalObject without involving ExecState. The API to do it through ExecState is the "old way" in my opinion. > + UString errorMessage = exception->toString(exec); > + JSObject* exceptionObject = exception->toObject(exec); > + int lineNumber = exceptionObject->get(exec, Identifier(exec, "line"))->toInt32(exec); > + UString exceptionSourceURL = exceptionObject->get(exec, Identifier(exec, "sourceURL"))->toString(exec); > + > + m_workerContext->thread()->messagingProxy()->postWorkerException(errorMessage, lineNumber, exceptionSourceURL); > + exec->clearException(); Here's the same code repeated again. I think this validates my request/suggestion that this be in a helper function. > + virtual void reportException(const String& errorMessage, int lineNumber, const String& sourceURL); Instead of having a default that does nothing, perhaps it would be better to have this be a pure virtual function. The default empty version is only handy if we expect to derive classes that want to leave this out. r=me as is -- please consider my suggestions.
Alexey Proskuryakov
Comment 3 2008-11-17 11:06:16 PST
Created attachment 25221 [details] updated patch
Alexey Proskuryakov
Comment 4 2008-11-19 00:38:25 PST
Comment on attachment 25215 [details] proposed patch Clearing review flag to get the obsoleted patch out of commit queue.
Darin Adler
Comment 5 2008-11-19 09:00:10 PST
Comment on attachment 25221 [details] updated patch > - Document::updateDocumentsRendering(); > + if (scriptExecutionContext->isDocument()) > + Document::updateDocumentsRendering(); Maybe this should be a virtual function on ScriptExecutionContext instead of a hard-coded rule at the callsite? > #include "WorkerContext.h" > +#include "WorkerMessagingProxy.h" > +#include "WorkerThread.h" > #include <parser/SourceCode.h> Why are you adding these includes to WorkerScriptController.cpp? r=me
Alexey Proskuryakov
Comment 6 2008-11-19 09:42:47 PST
Committed revision 38595. (In reply to comment #5) > Maybe this should be a virtual function on ScriptExecutionContext instead of a > hard-coded rule at the callsite? It looks alien in this function in either case, I'm not sure. > Why are you adding these includes to WorkerScriptController.cpp? That's simply a leftover from an earlier iteration - but these includes are now in this file for other reasons!
Note You need to log in before you can comment on or make changes to this bug.