If we want to make a checked exception, we can extend the Exception class, and for unchecked exceptions we can extend the RuntimeException class.
But the Exception class is a super for RuntimeException, so why can't I make a runtime exception class using the Exception class?
Extending Exception/RunTimeException in java?
That is just a feature of the language. Keep in mind that there are other Throwable classes, most notably Error and its children, none of which you are required to check for. Exception and RuntimeException are just markers in the inheritance tree that the compiler uses to check if a Throwable needs to be checked or not, pretty much because the authors of the language decided that those would be the names of those markers.
Related
Springboot provides #ControllerAdvice to handle exceptions in controllers.
But in service layer, there is no such annotations.
I've learned about spring-aop uses #AfterThrowing track exception, but #AfterThrowing cannot catch exceptions.
Another solution is to catch all exceptions with #Around, but it is kind of wastful to just log exceptions.
So, how to handle exceptions in service layer graceful?
The general idea is to let exceptions bubble up to controllers where they can be taken care of by components annotated with #ControllerAdvice or #RestControllerAdvice.
In order to achieve this you have to throw unchecked exceptions in your application when needed, i.e. if business validations fail. This also means that you have to catch any checked exceptions that might be thrown by third party dependencies and re-throw them as unchecked exceptions in your application, i.e. the infamous IOException and dozens of its sub-variants.
Apart from the above there's usually no need to handle exceptions in the #Service or the #Repository layer. There's rarely a reason to introduce aspects for any exception handling related logic either.
Recently I was wondering which class should I inherit in Kotlin if I want to create app-specific exception.
I noticed that I can inherit both: Kotlin's own Exception type and java.util.Exception.
So, I was looking for the answers: Exception or java.lang.Exception and Exception or RuntimeException (since Kotlin does not have checked exceptions, what is the difference)? Regarding second question: I feel like it is still better to use RuntimeException if Kotlin code can be invoked from Java in future (please correct me if I am wrong).
Regarding Exception I discovered that Kotlin's version is nothing more than the typealias on original Java Exception:
#SinceKotlin("1.1") public actual typealias Exception = java.lang.Exception
What is the purpose of having this typealias? The only advantage I see is you do not have to import java.lang.Exception, which makes your source code one-line-cleaner. Wondering if there is other motivation behind such typealiasing?
I typically extend from RuntimeException for the same reason you stated yourself, that there are no checked exceptions in kotlin, but either is fine.
The reason that there is a typealias of the java.lang.Exception within the kotlin-stdlib is to decouple your kotlin code from the java runtime/platform. This is because Jetbrains target other runtimes/platform. The aim is so that in theory you should be able to compile or transpile the same kotlin code to different platforms with minimal effort.
I am currently logging errors and would like to get the most descriptive details possible. I know I can catch many different types of exceptions but what is the difference between Exception.Message and Exception.InnerException.Message?
A program can catch an exception and re-raise a different exception, passing the original caught exception as the InnerException. The Exception(String, Exception) constructor does this for example. This happens in the .NET Framework itself, TypeInitializationException, TypeLoadException, TargetInvocationException, etc are raised this way.
The inner exception is completely unrelated to the raised exception and it is very, very important that you log the inner exception as well to have any hope of diagnosing the root cause of the problem.
The simplest way to do this is to use the ToString() method on the exception object. Which provides the exception message, the stack trace and iterates through the inner exceptions. Everything you need.
Let's think about an orchestration. The main activities takes place within a scope shape with 2 associated Catch Exception shapes: 1 for System.Exception and 1 General Exception. This orchestration makes use of a "helper" C# class library and the BizTalk scope/catch catches exceptions that are thrown within the library, as well as unhandled exceptions that occur within them.
The issue that I'm wondering about that I'm able to create is this: Say a version of the helper library gets published and suddenly there is a method missing that was previously there and the orchestration tries to call it. Inevitably a MissingMethodException is thrown, which seems to happen as soon as the Scope shape is reached.
The MissingMethodException is not caught by the orchestration and therefore the message is suspended. I realize that with proper testing this should never happen, but I'm just trying to cover all the bases should they happen (and really just out of curiosity).
Is there a way to catch these exceptions, or since it seems to happen at a level before the scope is called?
I figured it out. I had to wrap the entire scope which contained shapes there were utilizing my helper libraries in another scope as well. It appears that the .dlls (for the helper class library) must have been getting loaded and evaluated as soon as the scope is reached.
If you look at the attached image, my helper libraries are used in the "ValidateWrapper" expression shape, but the orchestration wasn't even making it there before a MissingMethodException was being called (due to a missing method in the helper class library), the "GeneralScope" shape was not able to catch the MissingMethodException but as soon as I wrapped the GeneralScope in another scope, the MissingMethodException was caught by that and could be handled.
This all happened because I updated the helper class resource through BizTalk admin console so the compiler wasn't able to warn of the missing method...but at least now I know I can catch the exception should it happen again.
You should know that exceptions in orchestrations within BizTalk are handled in a same way as in .NET: exceptions always inherit from the base class System.Exception.
Say for example you have a custom MissingMethodException (which inherits from System.Exception), then you can either catch MissingMethodException (to have any specific data) or System.Exception. Both will trigger the System.Exception exception handler if there is no specific MissingMethodException exception handler.
For more information, I would suggest reading http://www.codeproject.com/Articles/125470/Exception-Handling-for-C-Beginners
BizTalk orchestrations are no different than any other exceptions in .NET for that part.
Hope this helps.
The handlers I implemented override SimpleChannelHandler messageReceived, channelConnected and exceptionCaught methods.
Throwing a base Exception type means PMD complains "Signature Declare Throws Exception".
What is the best way to handle Netty exceptions so as not the throw base Exception types?
My guess is to remove the "throws Exception" from all my handlers. Then any exception that occurs will eventually get propagated up to the exceptionCaught() method in the last upstream/downstream Handler in the pipeline. Is this a correct assumption?
Although I happen to agree with PMD on this, the object model of Netty is different and uses a raw Exception. If you are programming against the Netty API, it would probably be better (for consistency, readability, etc.) to follow their model.
Don't let a static analysis tool be the deciding factor on your code. Sometimes there are exceptions (nice pun, not intended)