When I use enterprise application, I am usually greeted by some error that needs to consult help desk. I found many application still lean to use number as error code instead of a human readable string. Given most enterprise applications are written in modern language like java/C#, I can not figure out what's the benefit in using numeric error code.
So the question is, for enterprise application, is there a common adopted pattern for defining error code? is any reason number preferred to string?
BTW: I understand application using REST API likely use http status code for error code, this is understood as http status code itself is number. but for others, I don't understand
It's usually convenient to have both, a code, numeric or otherwise, and something human-readable.
The code makes it easy for machines to know what happened (and serve as shorthand for humans), and is verbiage- and locale- independent.
The single greatest benefit of error codes -- along with more informative strings -- is that they can be looked up even after your code has been translated into another language which you may not read.
The next greatest benefit is that if someone ever writes code that reads your error messages -- perhaps your own company, to help folks manage your appliction -- it is tremendously helpful for them to have an error code at the start of the message. That both speeds up their decision of what to do, and partially guards them against the risk that you might rephrase the message later (which would mess up attempts to search for the message text).
Any convention can work if you reliably stick with it. If you're thinking about the long term and multiple products, you'll probably want the code to include some indication of which code (application and/or library and/or other module) issued the error, and then you want to be able to quickly find the error in that product's support table.
IBM usually uses a moderately recognizable alphabetic prefix to identify the code, and a numeric suffix to indicate the specific message. Other companies probably do it differently.
I had recently similar problem and I have decided to use following rules:
Similar errors are grouped in types (in Java these would be Exception Classes)
Each error has enumerated value that identifies it (that is an error code)
Each error has human readable message
Errors optionally can have a cause (in many situations your errors were generated because some other error occurred, and that error is a cause)
You could argue about the need of the second rule since you could have as many types as possible errors. However if your system is growing, sooner or later you will find the need of introducing new types of errors, which will entail modification of your API and that's not always possible and even if it is, it might be not very easy since you will have to modify all of your clients. Enumerated error code list is simply easier to maintain in that case.
Related
Which is more suitable out of these two exception object (e) or e.getMessage() for log.info() and log.error() or log.debug().
What should be followed/rule of thumb for different logging levels.
It really depends on the reason of the exception being thrown. I would add here WARN level consideration as well. If this is an unexpected error that should not happen, meaning that this is something wrong with codebase you should definitely log the whole exception object, especially to get the stacktrace that allow developer to find and potentially fix issue faster. Therefore such situation should be logger on ERROR level if this is something wrong with the system, or WARN if this is something wrong with client's data.
INFO level should really not contain exception details, it should keep information easy to read by non-developers(for example testers) and describe the most important parts of the data processing flow.
I think it is up to you to put exception in DEBUG level but I would still recommend not to do it just to keep things clearer OR use e.getMessage() to describe it.
P.S. In general, I would redirect this question to this page since it is a general SE question but since you asked about using particular Java feature I wanted to keep things in the right place.
Don't try to create a fixed rule about including or not including the stacktrace depending on the log level. Instead, when creating a log entry, ask yourself:
Who will read that entry? A user, a system administrator, or a developer?
What information will be useful to that reader for understanding the situation? It's better to add too much information than to omit important parts.
If the entry is to be read by a developer, is the text enough or should I include the stacktrace? Non-developers typically get confused when seeing a stacktrace, but developers very much appreciate it.
This will greatly improve the quality of your logging.
As a very rough rule of thumb, include the stacktrace whenever you log an exception. An exception means that something went wrong, which might involve analysis by a developer, who will be very unhappy if the log entry only reads "NullPointerException" without a hint where it came from.
Of the typical log levels, INFO might be the one not addressing developers (thus not asking for a stacktrace), but generally you don't want to use INFO for exceptions.
I'm working on a Play 2 app which is being translated. Play uses Java's MessageFormat behind the scenes so I have a fair number of property values, ala:
my.interface.key={0,choice,0#{0} families|1#1 family|1<{0,number,integer} families}
I just received back a translation of this in the form:
my.interface.key={0,choix,0#{0} familles|1#1 famille|1<{0,nombre,entier} familles}
If it's not obvious, some bits of that should not have been translated, but mistakes will happen from time to time. That's fair enough, but I'm sure there must be a way of validating these strings prior to my app crashing at runtime with a IllegalArgumentException: unknown format type at ... exception. Preferably with a Git commit hook, or even an SBT build task.
If I was to hack this up myself I would probably make a tool to read these property files and check that, for each value, running MessageFormat.format(value) doesn't blow up.
Ideally I could do this via a Perl (or Python) script. Sadly, the only non-Java library I can find - Text::MessageFormat on CPAN - doesn't seem to support the most error-prone formats, such as pluralisation.
Can anyone suggest a more sensible approach based on existing tooling before I dive in?
We had a similar problem. Our solution was to create classes that model the structure of the message format, then use XML to define the messages in our message bundle.
If the translator uses an XML editor then there is some hope they won't "break" the structure of the message.
See this answer for details.
For example, two source codes are written in a way that both of them return a number and print out a random string(for example:"I have died number times") that number times. The important point in here is that the number that is returned from one program is the number that is added to the other program's string. One thing that should also be considered is that both programs hypothetically intervene others source code and then runs it forever. Which means the return value of the one program is actually the main factor to manipulate the other program.
Question: Is it doable,(for example in java) if so can a program alter its own source code?
Yes, it's do-able in theory. Self-modifying code is an entire branch of computer science.
It's rarely a good idea in the real world though, and if you are going to do it, Java (or other compiled languages) are probably not the best choice. Javascript, PHP¸ Python (e.g. What does Python's eval() do? ), Ruby, Groovy etc all offer ways to run arbitrary code, which itself could generate other arbitrary code... but it's nightmarish to debug, secure, test and prove that it's doing the right thing.
It's usually better to design your program carefully, and as another poster said, work with data structures, not with native source code.
Yes, it is possible and it is not so uncommon.
Libraries like Javassist can be used to manipulate code (byte code) during run-time. This is used e.g. for logging frameworks, profilers or stuff like Hibernate. All of those frameworks could inject new code into your existing code of your application, e.g. to monitor it.
I wrote a load balancer once, which could be started with an existing application. The load balancer was then taking the already compiled code of the application (which could be any JDBC application) and injected some control statements. All during run-time.
Instead of editing source code files (which would be an unwise path to go down, because you could accidentally mess up your source code), you could use a settings file, such as "number.ini". In this file, you can write a number, then the program would read this file and parse the number, print the string X amount of times (depending on what the number was), and then write a new number to this file.
This would eliminate the possibility of your source code being destroyed accidentally, and would remove any kind of "file in use" conflicts that may arise.
I've run Sonar on a project at work and found a violation 'The user-supplied array is stored directly'.
So looking a little deeper into what that means exactly I came across lots of stuff discussing it from security perspective (for example...). So when I read or hear 'security' I'm thinking malice, cracking, data breach and other grave consequences.
But I wonder what else could go wrong, especially in a load balance environment. Would this be a reason to worry about data contamination across sessions? One customers order data getting corrupted with someone else's details, etc?
Basically, you should consider this rule as very important if you're exposing a Java API to the rest of the world. The link you provided perfectly explains why (a consumer of your API would be able to change the array at any time if you don't clone it).
If violations occur in your internal implementations (that no one else will ever touch or use), you can lower the severity of the violations as there's no risk that a third-party code can modify the array. However, don't forget that code lives and evolves, and some day even your internal classes may be exposed to the rest of the world.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
We have been running into the problem of template errors occasionally sneaking into our production site. If there were a tool to catch these or a strategy to catch these problems ahead of time then it could be added to the delivery pipeline.
From my experience, Freemarker really only has two classes of errors when trying to render a template (Ignoring configuration):
Simple syntax errors at the template level
Assumptions about the model passed in at the Java level are incorrect
Although linting tools typically do find errors in code, a lint tool does not replace the need for basic testing, which is a far better solution for what you're experiencing here since you are seeing exceptions in production code.
For better or for worse, Freemarker's assumptions about who is working with the data and who is working with the markup are different people with different skillsets. Assuming this is the case (and you have Java engineering resources to spare), you have two ways of approaching this problem from a test process point of view (Although to be truly rigorous, you want both).
Frontend Testing
At my previous job, we used this approach by itself. Basically, the front-end engineers would hack templates on a special web frontend where the edited templates were directly on the configuration path containing two listings:
The template to render
Versions of the data model to render
The 'versions' were essentially a two-tiered set of hardcoded Java objects, where Tier 1 was consistent across all of templates, and Tier 2 was template-specific variations. Because most of our emails were account-level notifications, we got a lot of mileage and reuse out of just having the global data model, and we rarely had to dig into the small stuff.
Benefits
The Frontend engineers never need to touch Java, so you can use your HTML/CSS mavens for their intended purpose if that's what you have on your team
The Backend engineers can recycle a lot of stuff depending on the templates and their construction
Loosely enforces a uniformity of data model variable names when referring to frequently used values such as "account" (The Frontend engineers would get annoyed when values they expected weren't there because a different backend engineer named something 'incorrectly')
Not So Good
This basically is manual testing, and at some point will fail to catch an error
Backend Testing
The other alternative is form unit tests for each template as they are created. Because the exceptions in Freemarker all happen at compile time, you will only need to do the following (After you do initial setup):
Template temp = cfg.getTemplate("myTestedTemplate.ftl");
temp.process(myTestDataModel, myIgnoredOutput); // No exceptions -> OK for us
Note that you don't care about the result in this case, you just need it to compile. This is important because you can easily get bogged down in debugging compiled output in Java and not solve the current problem. As before, you will also want to do the same two-tiers of unit tests here in all likelihood:
Smoke test all templates with some generic model (Getting each template can likely be done programmatically)
Test individual templates with the variations in data model that you expect (Missing settings, incomplete fields, etc.)
Benefits
Part of the build/deploy process, so you eliminate human error in the templates
Depending on how you are using Freemarker, this can also verify the data models are being generated correctly by other processes if you aren't doing so already
Not-So-Good
Frontend Engineers will need to read stack traces to find out what failed
Development using this method ends up getting tied to your build process, which is nowhere near as fast as reloading a page
If you have the time to do both, I would recommend work on using unit tests to handle the edge cases and other concerns that you find as they pop up, then the web frontend for development so that developing the page doesn't require a recompile. The ability to version frontend is extremely beneficial, but the goal is to prevent errors in production to the build process first. Launch, then optimize and all.
If you mean runtime output errors and not template syntax errors, you could use a (brittle) set of "expect-got" integration tests. How appropriate this is depends on the complexity of your templates and how dynamic they are. If you just want some simple "smoke" tests, this is probably a good solution.
For each template, create at least one test. Using concrete/static/pre-specified input data and concrete/static/pre-specified output results. This output has to be manually generated and verified the first time after any change, but from then on it can be saved and testing can be scripted. If the template pulls in its own data (like dates, etc) that can't be set as fixed input, mask or remove this from the expected output. Each automated test should:
Generate "got" output from at least one set of input data for each template.
Mask or remove unpredictable variable regions from the output.
Compare this "got" result to the saved, pre-verified "expected" output.
Report failures when these are not the same.
Exact output equality is the easiest to implement and ensure are correct. If needed, have multiple tests per template. I wouldn't try to be clever, just let the computer do boring and repetative work. I would ignore the parts of the template that need to be masked on a first pass (some testing is better then none). Write explicit tests just for them later when you decide it improves reliability enough to be worth the effort (or for any that have been done wrong in the past.)
This solutions has the following caveats.
The scope is too large. Any change to anything in the template or in the data model can require updating the test. Using "diff" might help with manual verification and determining how to modify tests when data models and/or templates change.
Code refuse and modularity causes testing problems. With good, modular code, one code change can affect data in all templates, but static test require changing and reverifying all the tests independently when this happens. Not much to be done to fix that, so the better and more modular your code, the more work this causes :(
Sophisticated templates are hard to test. It might be problematic to have good template coverage using only a few sets of static data. That could mean the templates are doing too much "processing" and are not really being used just as template. That is probably not a good idea anyway.
I don't know about a tool that does this for you, but to catch the syntactical errors, all you have to do is giving all your template files to new Template("whatever", theTemplateFileReader);. Unfortunately, you can't detect runtime errors this way, such as references to non-existant variables/macros/imports. For that you could call Template.process, but without the data-model that you will have in the actual application it doesn't make sense of course.