I'm using #sentry/vue and I'm trying to catch only the errors that come from my module because currently I'm catching all the errors from the application.
On the Sentry documentation I can't find how to limit the scope to restrict and capture only the errors from my module.
Has anyone encountered this problem before?
Related
Our application is using CefSharp version 73.1.130. The issue only occurs on a small number of internal workstations within our organization. Worth noting, we are also seeing the same error with CefSharp version 92. Another strange thing is that it the issue is consistent, but only when the web apps are launched through certain navigations. Other navigations work consistently for these users.
We use RegisterJsObject to register a javascript object with browser. If I understand correctly, asynchronous binding is preferred moving forward.
The issue presents as strange/unexpected behavior in the hosted web application due to failure to retrieve context from the host WinForms application. The behavior would suggest a failure to register/bind the js object with the RegisterJsObject method. However, that method is not throwing an exception.
Enabled Cef logging showed the following error:
ERROR:JavascriptRootObjectWrapper.cpp(34)] IBrowserProcess is null, unable to bind object
After looking into the code, it appears the location that the value pointed to by "IBrowserProcess" is set is in WcfEnabledSubProcess::OnBrowserCreated (https://github.com/cefsharp/CefSharp/blob/cefsharp/73/CefSharp.BrowserSubprocess.Core/WcfEnabledSubProcess.cpp). I was able to build CefSharp and add additional logging to that method.
On my workstation (I'm not affected by the issue), I get through OnBrowserCreated with no exceptions. However, on my coworkers workstation I see the following line is failing:
...
channelFactory->Open();
auto browserProcess = channelFactory->CreateChannel();
auto clientChannel = ((IClientChannel^)browserProcess);
try
{
clientChannel->Open(); <-- FAILS
browser->ChannelFactory = channelFactory;
browser->BrowserProcess = browserProcess;
}
catch (Exception^)
{
}
}
With the error:
There was an error reading from the pipe: The pipe has been ended. (109, 0x6d)
Has anyone seen this issue before? I'm not sure how much this will help, but does anyone know if it's possible to enable WCF tracing with the CefSharp.BrowserSubProcess.exe. I have been trying this, but no luck so far.
require(["dojo/i18n!myapp/nls/extTools_i18nStrings"],function(extTools_i18nStrings){
// Do something with the loaded file
});
If the resource file (extTools_i18nStrings) has syntax error, it will be shown in dojo.js. How can I handle it in my code?
Try catch block did not work.
Thanks in advance.
Error: Script error .............dojo.js:15
The quick answer is you don't want to. The right thing to do is fix the bundle. This is the same as having errors in your application code, and you would not expect the code to 'handle' that.
But since i18n is an AMD plugin running as part of the loader (which is why you can't try/catch it), the error might be reported through the AMD micro event API, and you could use that to show a better error. I'm not sure how you 'handle' this syntax error other than showing an error.
If you can't control the quality of the bundles via some part of your development or build process you'd have to invent your own alternative to dojo/i18n and you probably don't want to go down that route for all of your bundles.
Should I use try/catch clause to write the PDO on the live site?
If I use try/catch clause to write it, all the errors details will appear on the web page. To prevent this happened, how do I know what errors are made without showing it on the web page?
That's a very good question, and - to my utter surprise - an extremely rare one. As though there are no developers running a live site around. And all the answers we have here is a mere proof for this surprising statement.
Should I use try/catch clause to write the PDO on the live site?
Of course no.
If I use try/catch clause to write it, all the errors details will appear on the web page.
It is not actually because of try-catch but because you're echoing them in that block yourself. But anyway, you shouldn't use that block either.
To prevent this happened, how do I know what errors are made without showing it on the web page?
You have to let them to be logged. To do so, you shouldn't use try-catch in the first place. Despite of all the wrong examples over the net, this operator has very little to do with reporting errors, and have to be used to handle errors, not to report them.
Surprisingly, PHP is very good at error logging. You won't believe me, but it can handle such a laborous task itself. Instead of wrapping each and every sql statement in try-catch, just leave them alone. In case of error, an exception will be thrown, yet uncaught exception is a fatal error. And for a live site you should have set error logging mode already. Means your PDO error will be logged as well.
As a result, to let yourself know what happened, all you need is to peek into error log.
In a nutshell, you shouldn't treat PDO error as something special. In either way, it's yet another error that happened in your code. Exactly the same as memory overflow error, or file not found error, or permission denied error. There is no special meaning in PDO errors and there is not a single reason to handle them in any special way. Just treat them as any other error in your site. In dev environment happily echo them on the screen for easy debugging, while on the live site disable error displaying and enable error logging, and you're set. I.e.
for a dev server:
error_reporting(E_ALL);
ini_set('display_errors',1);
ini_set('log_errors',1);
while for a live one
error_reporting(E_ALL);
ini_set('display_errors',0);
ini_set('log_errors',1);
I'm working on an API project and have to decide over the error handling and logging strategy/concept. So as first step I want to check, whether Apigility provides its own logging functionality.
If I see it correctly, Apigility only provides a minimal error handling for REST specific errors (Apigility documentation -> Error Reporting). That's it. So, only a limited error handling and no logging. Right? But maybe it's wrong and I have just not found the functionality I need. So, is an error handling mechanism provided? Is a logging mechanism provided in Apigility?
It handles error rendering if you use ApiProblem objects to encapsulate your errors.
It doesn't handle logging out of the box, you'll have to add your application's logging strategy yourself.
All of a sudden the errors that Dojo (1.8.3 from Google CDN) is spitting out empty errors, which makes debugging impossibly hard. For example, if I forget to require a dependent before using it, I get the usual
> dojo/parser::parse() error ReferenceError {}
... in the error console, but I remember getting more information in the ReferenceError (spindown arrow was present), giving me the arguments of the error as well as the message making it easy to figure out what I had done wrong.
I have isDebug : true in my dojoConfig, but it just doesn't want to tell me anything anymore.
What gives?
I've been having the same problem using Dojo 1.8.3 as well. When I close my developer tool's console and then re-open it the Error had the spindown and more details as expected. Seems stupid, but give it a try and see if that at "fixes" it for you. I planned on digging a little further into this later, so if I find any additional details I will make sure to update my answer with them.