I need a way to catch all scrappy exceptions without writing try catch everywhere.
I think about to utilize process_spider_exception() in middleware but it will run multiple times for an exception
Related
I have my own exception in my application. And the moment I throw it like this:
throw new CChristianLifeMinistryEntryException(strError);
Understandably code analysis triggers this because I have used new.
It is suggesting that I use make_unique and I am trying to establish if that is the correct way to update this code.
In C++ exceptions are normally derived from std::exception and are thrown by value, and caught by reference. This way you don't need to manage lifetime (don't need to delete some exceptions after handling and not delete others).
Like throw std::runtime_error(str_error);.
MFC's approach of throwing reference with new predates C++ compiler exception support, so there was a way to throw a pointer exception, but not arbitrary type of exception. It is not recommended for the new code.
There's special smart pointer for exceptions called exception_ptr, it is usually needed to transfer exceptions between threads, not to wrap exceptions being thrown.
If you wrap an exception with unique_ptr, you'll have to catch it wrapped, and this catch will not catch derived exception, because different unique_ptr and not derived from each other, so wrapping exceptions this way is definitely not a good idea.
I have a custom Run time exception i throw it in server side. What I want is to re-throw it and catch it in client side. what do I do? I have searched it but I didn't find anything. All I found were "RMI" and "GWT".
It is not possible directly, but some frameworks like RMI are capable of serializing the exception over network and then re-throwing on the client side, directly, or more often wrapped into some kind of RemoteException. This is one of the reasons why Java exceptions are serializable.
If you are using such a framework, it is possible to throw an exception on one end and get a remote exception on another end of the communication channel.
I know that a question like this probably depends on what the programmer intends his program to do however at school we were taught to never throw or catch Exception (the class) and rather make sure it throws one of the subclasses more specific to the kind of Runtime error we expect can happen (eg IllegalArgumentException). However, I'm working now and in the 'real world' I see a lot of scenarios in code I work on where the previous programmers threw Exception for everything in a method or catch Exception like that rather than one of its more specific subclasses.
So I'm wondering, Is it ok to throw and catch everything like this, is it bad programming to do so?
My idea is, the way of handle the exceptions should also depend on the type of the application you are creating. For example if you are developing some kind of a framework or a library you should not try to print error messages or log them, you have throw them because it will be responsibility of the other developers who are using your framework/library to handle the exceptions gracefully when they are using your code.
If you are developing some kind of a front end application then you should be more delicate with exception handling. I think it's better you use you own exception classes when possible, because that will help you to pin point the bugs or runtime issues in your application later. When you handle exceptions you should always go from more specific exceptions to general exceptions. And finally you should handle the exceptions of the "Exception" super class so it will make sure that your application doesn't crash, preferably you should have a try-catch block in the main entry point of your application. What ever happens in handling exceptions logging the errors is a good practice when it comes diagnosing the errors later.
It is not wrong to do that but it can make your debugging life very difficult. Many people will catch the exception class and log the Exception.Message. There is not enough detail and, especially if you're working on large systems where you can't always step through the live code etc, it will be a tedious task.
I tend to catch specific exceptions and handle them accordingly BUT I also catch the Exception class to make sure all exceptions are caught going forward (An object might be changed to include more exceptions in future framework versions).
It is bad practice, just as you have learnt.
One major exception to the rule is a top-level exception handler (to catch unhandled exceptions) - the purpose of this would be to log exception so they can be read by a developer later and used to fix the application (and would normally rethrow in order to crash the application - rather than leaving it in an inconsistent state).
I have a function that processes an image whose path is given by the user. I'm a bit new to Mathematica, and I can't find much on its large documentation. How can I throw an exception when Import[myFile] fails? Can I even do that?
Thanks a lot.
A simple prototype is
Catch[
Check[img = Import["myFile"], Throw[$Failed], Import::nffil];
Print["Processing image"]
]
Where you can make the Catch and Throw more targeted by using tags if need be.
You can use Throw[anyExpression] or Throw[anyExpression, exceptionTag] to throw an exception, with any expression. You can then use Catch[your code] or Catch[yourCode,exceptionPattern]. Exceptions in Mathematica are not objects like in e.g. Java, so you can not directly use the technique of building exception inheritance hierarchies and use multiple catch statements to catch from more specific to more general. Exception tags are needed to give an exception an identity, somewhat similar to exception class name in Java. Throw without a second argument will throw an untagged exception, which can be caught by Catch without a second argument. If you seriously want to use exceptions in Mathematica, I would advice against such usage, since you can easily catch something you did not plan to catch - just as you wouldn't normally use Exception in Java, but would rather subclass it. There are no checked exceptions in Mathematica, so all Mathematica exceptions can be considered run-time exceptions. Since the second argument of Catch is a pattern, you can construct Catch commands that would be able to catch exceptions with different tags, somewhat emulating the exception inheritance hierarchies of Java. The syntax is also different - there is no try - you just wrap Catch around a piece of code from where you may expect an exception. Note that Catch with no second argument won't catch a tagged exception, while Catch with the second argument won't catch an untagged exception. If you want both, you may need to nest like Catch[Catch[code,pattern]]. There is no finally clause provided as a built-in, but one may emulate it with a user-defined code, since in Mathematica one can program the control flow constructs as well, using non-strandard evaluation (functions with Hold-attributes etc). You can look for use cases of Catch and Throw in the documentation, here on SO posts,and on MathGroup, and you will find plenty o good examples.
HTH
It is quite tiresome writing try/catches in every method block.
Apart from AOP, is there any way to avoid this and catch all exceptions? Would it be enough to just catch them at the global error handler level (e.g. as in ASP.NET).
Thanks
The best advice I've heard on the subject (somewhere on SO, actually) was "only catch an exception if you're going to handle it." That is, it only makes sense to use a catch block in that method if that method has the means of handling the exception. For example, if the method should for some reason always return a value, and the exception is either silently logged or somehow indicated in the value (such as an error message attached to some custom DTO or something). There's nothing wrong with bubbling the exception upward in the stack and assuming the caller will handle it.
That's not to say, of course, that it shouldn't be handled at all. As you suggest, the last line of defense should always be the global exception handling for the application. All fails should be handled gracefully, but they should more importantly be handled only by the class/method that is supposed to handle them, which in many cases is not the method from which the exception originated. For example, in a simple forms over data web app, the data access doesn't necessarily need to handle the exception. It can add information to it if pertinent, but for such a simple app the global error handler can take care of logging and presenting an error message.
It should also be noted (I'm assuming you're talking about .NET here) that a try block need not always be accompanied by a catch block. You can try{}finally{} to take care of cleaning up after an exception (such as gracefully closing an external resource) without bothering to catch the exception and instead let it bubble up accordingly.
I agree with David. Here's my basic set of rules, or ... like the pirate code, guidelines ...
There should always be one global exception handler to catch runtimes and anything else that the classes cannot handle.
Try/catch should only be implemented when you can actually do something about the exception. And No, logging the exception is not doing something about it.
Adding a throws or Throwing a Exception or RuntimeException should be avoided. If you have a wide or large number of exceptions to deal with, create a new exception class to wrap them. Exception is too general and creates problems for other developers.
Try/catch blocks are expensive, do don't put them in unless necessary.
Never, and I mean NEVER !!! use try/catch for logic flow.
I've found it helpful to think of your code as having three layers, and using an exception strategy appropriate to each layer. I wrote up the details in Exceptions in the Rainforest.