Related
I am coding a function which gets called via RFC and I want to find the most simple way to raise an exception with a custom message in ABAP. It would be great, if this could be done as short as possible, if possible on one line.
I want this for debugging, not for running production code.
Background:
In the past I used the Python programming language. I like to debug without a debugger. I put some assert 0, myvar lines in to the code and execute the code. For me this feels faster then tradition debugger with stepping over or into code lines. I am searching for an equivalent to assert 0, mvar in ABAP.
Raising an exception is just the strategy I have on my mind at the moment. Every other strategy to get to the overall goal is welcome.
As you already found out, MESSAGE text TYPE 'E' will let you throw arbitrary messages that abort program execution. You could also choose 'A' as a type. However, do not use this to test your code.
There are several reasons for this:
As the documentation of MESSAGE explicitly states, MESSAGE is intended exclusively to interact with the user and should only be used in the layor of your code closest to the user interface. The exact behaviour of messages is difficult to predict, since it depends on the processing mode in which your code is executed, cf. the documentation of message behavior. If you absolutely must, use ASSERT instead, which has much more consistent behavior.
You should not alter your production code for testing purposes. Test code and production code should be as disjoint as possible, since otherwise you run the risk of accidentally leaving code purely intended for testing in your production code. These days, ABAP offers a powerful unit testing framework in the form of ABAP Unit. The assertion methods of cl_abap_unit_assert all offer a msg parameter with which you can define very specific error messages for failing tests. This allows you to do detailed testing without having to alter production code (if you designed it to be testable).
Both MESSAGE and ASSERT produce short dumps. In development systems, this is usually not seen as that bad, but you should avoid producing short dumps if you can, since it makes it harder for readers of e.g. the ST22 logs to distinguish true unforeseen error situations in mature code from failed tests during active development. A failing unit test does not dump, and is just as useful.
There is ASSERT statement in ABAP that you could use in a similar way to your Python case.
Here is a docu:
ASSERT
I found that this works:
message my_string_var type 'E'.
I add the MESSAGE TYPE 'E' only temporary into the code. I test my ABAP code from outside (via PyRFC).
I tried to find resources on what is the standardised and accepted idiomatic D-way of handling errors, but I couldn't find any. If one is reading the official documentation on error handling, then one finds the following very important statements there:
Errors are not part of the normal flow of a program. Errors are exceptional, unusual, and unexpected.
Because errors are unusual, execution of error handling code is not performance critical.
The normal flow of program logic is performance critical.
I call them important, because the reasoning on using exceptions for such, well, exceptional cases is what leads the article towards the conclusion, that errors are special cases after all, and exceptions are the way to go, no matter what the costs are. Again from the same article:
Because errors are unusual, execution of error handling code is not performance critical. Exception handling stack unwinding is a relatively slow process.
In some special cases, where the exceptions may not be handled explicitly, but their presence should effect the state of things anyway, one should use the exception safe scope guards.
My main problem is, the above mentioned solutions and their examples in the documentations are indeed exceptional cases, which are pretty useful when we are hitting for example memory-related problems, but we don't want our program to fail, we want to maintain integrity and recover from those scenarios if possible, but what about other cases?
As we all know errors are not only used for exceptional cases and unexpected scenarios, but they are ways of communicating between callers and callees. For example errors can be used in a sanitiser. Let's say we want to implement a schema validation for an associative array. The type system alone is not capable of defining the constraints of the keys and values, so we create a function to check such objects during run time. So what should happen if the schema fails? Since we are interested on how it fails, the error that happened in it (that is, invalid data found) should also contain the information on what went wrong, therefore the caller would know how to act upon on it. Using exceptions is an expensive abstraction according to the author of the first article. Using the C-style function conventions, where the return values are all used for error states is the wrong way according to the same author in the same article.
So, what is the proper and idiomatic way of handling errors that are not exceptions in D?
Well, the TLDR version is that using exceptions is the idiomatic way to handle error conditions in D, but of course, the details get a bit more complicated than that.
Part of the question is what constitutes an error. The term error is used for many things, and as a result, talking about errors can be quite confusing. Some classes of errors are programmatic errors (and thus the result of bugs in the program), others aren't programmatic errors but are so catastrophic that the program can't continue, and others depend on stuff like user input and can often be recovered from.
For programmatic errors and catastrophic errors, D has the Error class, which derives from Throwable. Two of the commonly used subclasses of Error are AssertError and RangeError - AssertError being the result of a failed assertion, and RangeError being what you get when you try to index an array with an index that's out-of-bounds. Both of those are programmatic errors; they're the result of bugs in your program, and recovering from them makes no sense, because by definition, your program is in an invalid state at that point. An example of an error that's not a bug but which is generally catastrophic enough that your program should be terminated is MemoryError, which is thrown when new fails to allocate memory.
When an Error is thrown, there is no guarantee that any clean-up code will be run (e.g. destructors and scope statements may be skipped, because the assumption is that because your code is in an invalid state, the clean-up code could actually make things worse). The program simply unwinds the stack, prints out the Error's message and stack trace, and terminates your program. So, attempting to catch an Error and have the program continue is almost always a terrible idea, because the program is in an unknown and invalid state. If something is considered an Error, then it is the sort of condition where the error condition is considered unrecoverable, and programs should not be attempting to recover from it.
For the most part, you probably won't do anything explicit with Errors. You'll put assertions in your code to catch bugs when not compiling with -release, but you probably won't be throwing any Errors explicitly. They're mostly the result of D's runtime or assertions in code you're running catching bugs in your program.
The other class that derives from Throwable is Exception. It's used for cases where the problem is not a bug in your program but rather a problem due to user input or the environment (e.g. the XML that the user provided is invalid, or a file that your program attempts to open does not exist). Exceptions provide a way for a function to report that its input was invalid or that it's unable to complete its task due to issues outside its control. The program can then choose to catch that Exception and try to recover from it, or it can let it bubble up to the top and kill the program (though typically, it's more user-friendly to catch them and print out something more user-friendly than a message with a stack trace). Unlike Errors, Exceptions do result in all clean-up code being run. So, it's completely safe to catch them and continue executing.
However, what the program can do in response to the exception and whether it can do more than report to the user that an error occurred and terminate depends on what the exception was and what the program is doing (which is part of why some code subclasses Exception - it provides a way to report what went wrong beyond just an error message and allows the program to respond to it programmatically based on the type of thing that went wrong rather than simply responding to the fact that "something" went wrong). By using exceptions to report when something goes wrong, it allows for code to not directly handle errors unless it's the place in the code that you want to be handling errors, resulting in much cleaner code overall but with the downside that you can sometimes get exceptions being thrown that you weren't expecting if you weren't familiar enough with what could be thrown when. But that also means that errors that are reported don't get missed like they can be with error codes. If you forget to handle an exception, you'll know it when it happens, whereas with something like an error code, it's easy to forget to check it or not realize that you need to, and errors can be missed. So, while unexpected exceptions can be annoying, they help ensure that you catch problems in your program when they occur.
Now, the best time to use assertions vs exceptions can be a bit of an art. For instance, with Design by Contract, you use assertions to check the input to a function, because any code that calls that function with invalid arguments is in violation of the contract and therefore considered buggy, whereas in defensive programming, you don't assume that the input is valid, so the function always checks its input (not just when not compiling with -release), and it throws an Exception on failure. Which approach makes more sense depends on what you're doing and where the input for the function is likely to come from. But it's never appropriate to use assertions to check user input or anything that is outside of the program's control, because bad input is not a bug in the program.
However, while in general, the idiomatic way to handle error cases in D may be to throw an exception, there are times where that really doesn't make sense. For instance, if the error condition is actually extremely likely to occur, throwing an exception is an awfully expensive way to handle it. Exceptions are generally fast enough for cases that aren't happening all the time, but for something that happens frequently - especially in performance-critical code - they can be too expensive. And in such cases, doing something like an error code can make more sense - or doing something like returning a Nullable and having it be null when the function failed to get a result.
In general, exceptions make the most sense when it's reasonable to assume that the function will succeed and/or when it streamlines the code to make it so that it doesn't have to worry about the error condition.
For instance, imagine writing an XML parser that used error codes instead of exceptions. Each function in its implementation would have to be checking whether any function it called succeeded and return whether it itself succeeded, which would not only be error-prone, but it would mean that you'd essentially have error-handling code everywhere throughout the parser. On the other hand, if you use exceptions, then most of the parser doesn't have to care about errors in the XML. Instead of code that encounters invalid XML having to return an error code that the function calling it has to deal with, it can just throw an exception, and whatever code in the call chain is actually a good place to handle the error (probably the code that called the parser in the first place) is then the only code that has to deal with the error. The only error handling code in your program is then code that needs to deal with errors rather than most of your program. The code is much cleaner that way.
Another example where exceptions really clean up code would be a function like std.file.isDir. It returns whether the file name it's given corresponds to a directory and throws a FileException when something goes wrong (e.g. the file doesn't exist, or the user doesn't have permission to access it). For that to work with an error code, you'd be stuck doing something like
int isDir(string filename, ref bool result);
which means that you can't simply put it in a condition like
if(file.isDir)
{
...
}
You'd be stuck with something ugly like
bool result;
immutable error = file.isDir(result);
if(error != 0)
{
...
}
else if(result)
{
...
}
It's true that in many cases, there's a high risk of the file not existing, which would be an argument for using error codes, but std.file.exists makes it possible to easily check for that condition before calling isDir and thus ensure that isDir failing is the uncommon case - or if the code in question is written in a way that it's highly likely that the file exists (e.g. it was gotten from dirEntries), then you don't have to bother checking whether the file exists. Either way, the result is much cleaner and less error-prone than dealing with error codes.
In any case, the most appropriate solution depends on what your code is doing, and there are cases where exceptions really don't make sense, but in general, they are the idiomatic way to deal with errors that are not bugs in your program or catastrophic errors like running out of memory, and Error's are normally the best way to deal with encountering bugs in your program or catastrophic errors. Ultimately though, it is a bit of art to know when and how to use exceptions vs other techniques, and it generally takes experience to have a good feel for it, which is part of why questions about when to use exceptions, assertions, and error codes pop up from time to time.
I read several posts on exception handling/rethrowing exceptions on here (by looking at the highest voted threads), but I am slightly confused:
-Why would you not want the immediate catch block to handle an exception but rather something above it?
-Also, I read quite frequently that you should only handle exceptions which you can "handle". Does that mean actually doing something about it, such as retrying the operation?
You might want to catch an exception (e.g. file not found) and do some processing - e.g. if you open two files and the second file is missing, you will want to close the first file again before you continue, so that it isn't left open.
You might then want to tell the caller that an error occurred, so you re-throw the same exception or throw a new exception, describing the problem.
In some cases, if you get an exception, your code has no way of knowing if it is an error or not (e.g. if you are asked to load an XML file, but you get a File Not Found exception, is that an error, or should you return a blank XMl result?). In these cases you either want to re-throw the exception, or not handle it all all, and let the calling code decide how to deal with the problem.
Your second point is the answer to the first. Sometimes the lower-level functionality does not know enough about the context of the application to know what the right action should be. For example, if opening a file for reading fails because there is no file of that name, then the application might want to ask for a different file, or abort the whole operation, or whatever. At some level, some part of the application will take the responsibility to do the right thing, unless of course just having the program crash is an acceptable action to take.
Answering to your second question - you need to handle the exception in the immediate block only if can do anything about it: for example close connection to db, close streams, retry or retry with different params, log exception (if there will not be an exception generic handler on the higher levels). Probably only immediate block of code knows such details and can handle them. Calling blocks need to know that the error occurred they might know better what to do with exception.
For example immediate block works with a file. A caller might try to open a file from different locations(In the process of "probing") and ignore several errors as long as at least one succeeds. Another part of code might consider the very first failed attempt as an error. Caller block might chose to notify the user that an error is occurred, probably let her/him know some helpful info on how to fix the problem. Also it is nice to provide the means to notify support of the problem – some kind of dialog allowing user to ask for help, describe problem and send a message. In this message you might attach logs, some info about the environment like OS, versions of frameworks, programs, browser capabilities whatever you need to diagnose the problem (if user permits you to do so).
An exception is "handled" if the method which caught it can satisfy its construct. For example, the contract for a routine OpenRecentDocument which is called when the user selects an item from the "recent files" menu might specify that it must either (1) successfully open a document window, or (2) try unsuccessfully to open a document window, roll back any side-effects resulting from the attempt, and notify the user of the what happened. If OpenRecentDocument catches an exception while trying to open the file, but it is able to roll back any side effects from the attempt and notify the user, the routine will have satisfied its contract and should thus return without rethrowing the exception.
One unfortunate "gotcha" in all this is that there isn't any standard means by which routines which throw an exception can indicate whether their attempted operation has resulted in side-effects which could not be rolled back. There is no inherent way, for example, of distinguishing an InvalidOperationException which occurs unexpectedly while updating a shared data structure (which would imply that other open documents may have been corrupted), from an InvalidOperationException which occurs while updating the data associated with the document being loaded, even if one has anticipated the latter possibility and provided for it. The best one can do is either try to catch any InvalidOperationException which might occur in the latter situation near the spot that it occurs, encapsulate that exception in some other exception type, and throw that, or else have data structures maintain an "object corrupted" flag and ensure that if a data structure is found to be corrupt, all future operations on it will fail as cleanly as possible. Neither approach is at all elegant. The more common approach, which could probably be described as "hope for the best", usually works.
My VS just told me;
Warning 2 CA1031 : Microsoft.Design : Modify 'Program.Main(string[])' to catch a more specific exception than 'Exception' or rethrow the exception.
Why should I do that? If I do so, and don't catch all exceptions to handle them, my program crashes with the all-popular report-screen. I don't want my users to get such error-crap!
Why should I not catch all exceptions at once to display a nice warning to the user saying: "Something went wrong, don't care about it, I will handle it, just be patient"?
Edit: Just saw I have a dupe here, sorry for that Dupe
Edit2: To clarify things; I do exit the program after any exception has been catched! I just don't want my user to see that "report to microsoft" dialog that show up when an unhandled exception is raised in a console-application!
Swallowing exceptions is a dangerous practice because:
It can cause the user to think something succeeded when it actually failed.
It can put your application into states that you didn't plan for.
It complicates debugging, since it's much harder to find out where the failure happened when you're dealing with bizarre/broken behavior instead of a stack trace.
As you can probably imagine, some of these outcomes can be extremely catastrophic, so doing this right is an important habbit.
Best Practice
First off, code defensively so that exceptions don't occur any more than necessary. They're computationally expensive.
Handle the expected exceptions at a granular level (for example: FileNotFoundException) when possible.
For unexpected exceptions, you can do one of two things:
Let them bubble up normally and cause a crash
Catch them and fail gracefully
Fail Gracefully?
Let's say you're working in ASP.Net and you don't want to show the yellow screen of death to your users, but you also don't want problems to be hidden from the dev team.
In our applications, we usually catch unhandled exceptions in global.asax and then do logging and send out notification emails. We also show a more friendly error page, which can be configured in web.config using the customErrors tag.
That's our last line of defense, and if we end up getting an email we jump on it right away.
That type of pattern is not the same as just swallowing exceptions, where you have an empty Catch block that only exists to "pretend" that the exception did not occur.
Other Notes
In VS2010, there's something called intellitrace coming that will allow you to actually email the application state back home and step through code, examine variable values at the time of the exception, and so on. That's going to be extremely useful.
Because programs that swallow (catch) exceptions indiscriminately, (and then continue), cannot be relied upon to do what it is they are expected to do. This is because you have no idea what kind of exception was "ignored". What if there was an overflow or memory access error that causes the wrong amount to be debited from a financial account? What if it steers the ship into the iceberg instead of away from it ? Unexpected failures should always cause the application to terminate. That forces the development process to identify and correct the exceptions it finds, (crashes during demos are a wonderful motivator), and, in production, allows appropriately designed backup systems to react when the software experiences an "unexpected" inability to do what it was designed to do.
EDIT: To clarify distinctions between UI components, and service or middleware componentrs.
In Service or Middleware components, where there is no user interacting with the code component from within the same process space that the code is running in, the component needs to "pass On" the exception to whatever client component imnitiated the call it is currently processing. No matter the exception, it should make every possible attempt to do this. It is still the case, however, tjhat in cases where an unexpected, or unanticipated exception occurs, the component should finally terminate the process it is running in. For anticipated or expected exceptions, a velopment analysis should be done to determine whether or not, for that specific exception, the component and it's host process can continue to operate (handling future requests), or whether it should be terminated.
You should handle the exact exceptions you are capable of handling and let all others bubble up. If it displays a message to the user that means you don't quite know what you can handle.
Having worked on equipment used by emergency responders, I would rather the user see an ugly error message than to accidently swallow an exception that misleads the user into believing everything is "ok". Depending on your application, the consequence could be anything from nothing to a lost sale to a catastrophic loss of life.
If a person were going to catch all exception, show a better error dialog, and then quit the application, that's ok.. but if they are going to continue running after swallowing an unknown exception, I would fire a person for that. It's not ok. Ever.
Good coding is about practices that assume humans make mistakes. Assuming all "critical" exceptions have been caught and handled is a bad idea.
Simple answer: you are supposed to fix your bug. Find the place that throws the exception and unless it is beyond your control - fix it.
Also catching (without rethrowing) all kinds of exception violates exception neutrality. In general you do not want to do this (although catching exceptions in main does look like special case)
Since your warning message shows that this is in Main(), I'll assume that in lower levels, you do catch only more specific Exceptions.
For Main(), I'd consider two cases:
Your own (debugging) build, where you want all the exception information you can get: Do not catch any Exceptions here, so the debugger breaks and you have your call stack,
Your public releases, where you want the application to behave normally: Catch Exception and display a nice message. This is always better (for the average user) than the 'send report' window.
To do this nicely, just check if DEBUG is defined (and define it, if VS doesn't do this automatically):
#if DEBUG
yadda(); // Check only specific Exception types here
#else
try
{
yadda();
}
catch (Exception e)
{
ShowMessage(e); // Show friendly message to user
}
#endif
I'd disable the warning about catching general Exceptions, but only for your Main() function, catching Exception in any other method is unwise, as other posters have said already.
There is a way to suppress certain messages from code analysis. I've used this for this exact reason (catching the general exception for logging purposes) and it's been pretty handy. When you add this attribute, it shows you've at least acknowledged that you are breaking the rule for a specific reason. You also still get your warning for catch blocks that are incorrect (catching the general exception for purposes other than logging).
MSDN SuppressMessageAttribute
I am all for catching specific known exceptions and handling state...but I use general catch exceptions to quickly localize problems and pass errors up to calling methods which handle state just fine. During development as those are caught, they have a place right next to the general exception and are handled once in release.
I believe one should attempt to remove these once the code goes into production, but to constantly be nagged during the initial code creation is a bit much.
Hence turn off (uncheck) the warning by the project settings as found in Microsoft.CodeQuality.Analyzers. That is found in the project settings under Code Analysis:
All answers are good here. But I would mention one more option.
The intention of author to show some fancy message is understandable.
Also, default Windows error message is really ugly. Besides, if application is not submitted to "Windows Excellence Program" the developer will not receive information about this problem. So what is the point to use default runtime handler if it does not help?
The thing here is that default exception handler of CLR host ( https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2008/9x0wh2z3(v=vs.90)?redirectedfrom=MSDN ) works in a very safe way. The purpose of it is clear: log the error, send it to developer, set the return code of your process and kill it. The general way of how to change that is to write your own host. In this case you can provide your own way of handling exceptions.
Still, there is an easy solution which satisfies CA1031 and still most of your needs.
When catching the exception, you can handle it your own way (log, show the message etc) and at the end you can set the process result code and do the exit (using the mix of Thread.Abort and "Exit" methods, for example). Still, at the end of your catch block you can just put "throw;" (which will never be called because of ThreadAbortedException, but will satisfy the rule). Still there are some cases, like StackOverflowException, which can't be handled like that and you will see that default message box, for fixing which you need to fallback to custom CLR host option.
Additionally, just for your information, you application can run several threads (besides that one which execute Main method). To receive exceptions from all of them you can use AppDomain.UnhandledException. This event does not allow you to "mark" the exception as handled, still you can freeze the thread using Thread.Join() and then do the job (log, msgbox, exit) using another (one more) thread.
I understand all this looks a little tricky and may be not right, but we have to deal with the implementation of AppDomain.UnhandledException, ThreadAbortException, CorruptedState exceptions and default CLR host. All of this eventually does not leave us much of choice.
When you catch general exceptions, you get the side effect of potentially hiding run-time problems from the user which, in turn, can complicate debugging. Also, by catching general exception, you're ignoring a problem (which you're probably throwing elsewhere).
You can set up your try catch to catch multiple different behavior types and handle the exception based on the type. For most methods and properties in the framework, you can also see what exceptions they are capable of throwing. So unless you are catching an exception from an extremely small block of code, you should probably catch specific exceptions.
In VS you can setup a custom error page to show your users when something goes wrong instead of catching it in a try-catch. I'm assuming since you're using VS that you're using ASP .NET. If so add this tag to your Web.Config under the System.Web tag:
<customErrors mode="RemoteOnly" defaultRedirect="~/CustomErrorPage.aspx" redirectMode="ResponseRewrite" />
You can also catch all uncaught exceptions in the Global.asax file (if you don't have it already: Right-click on web project, select Add Item, and search for it). There are a bunch of application wide event handlers in that file like "Application_Error" that catches every exception that isn't caught within your application so you don't have to use Try-Catch all the time. This is good to use to send yourself an email if an exception occurs and possibly redirect them to your homepage or something if you don't want to use the customErrors tag above.
But ultimately you don't want to wrap your entire application in a try-catch nor do you want to catch a general Exception. Try-catches generally slow down your application and a lot of times if you catch every general exception than it could be possible that you wouldn't know a bug exists until months or years later because the try-catch caused you to overlook it.
Are there any situations when you would use assertion instead of exceptions-handling inside domain classes...
Use exceptions for parameter validation and other checks which verify that the users of you classes use them as intended.
Use assertions for internal consistency checks, i.e. to indicate you screwed up, not the user of your class.
Thus, if users of your class see an assertion failure, they know it is (probably) an internal error in your code, not in their use of your code. On the other hand, if the get parameter validation exception, they know it's their fault.
Never. Assertions are not a valid form of error-handling. Use them to assist in identifying program errors during testing.
An assertion reflects a state that should not ever occur and was not expected, where the application cannot continue executing for one reason or another, whereas an exception indicates a state that is not considered "normal", but that was not unexpected, and from which it might be possible to recover.
As an example, if I allocate space on the heap, and this allocation fails, then I can't continue working, so I assert that the address returned is valid; where it is invalid, the assertion fails, and the program fails with it.
On the other hand, if I open a file for reading, and it doesn't exist, then it might be possible to recover from the situation, in which case an exception is thrown (and caught, and handled as far as possible).
In general, assertions are most useful during the debugging phase, whereas exceptions are considered part of regular program flow and error handling. The general consensus is that assertions should be disabled in production code (to shield users from apparent crashes), whereas I have read a school of thought that argues this is counter-productive, and that the user should see the assertion failure, so that they can properly report the problem.
Personally, I sometimes combine the two techniques; usually, if I'm catching an exception that I do not believe could be thrown. Taking the example above, if I check the file's existence before attempting to open it, then I do not expect an exception to be thrown, and if one is, then I tend to deal with this by raising an assertion in the relevant catch block. I find this a particularly useful technique in Java, where such exceptions are fully checked.