# Tag Info

## New answers tagged error-handling

0

Two of the most important principles in maintainable software design are KISS and YAGNI. KISS: Keep it Simple, Stupid YAGNI: You Aren't Gonna Need It It is almost never a good idea to put in logic you don't immediately need right now. Among many other people, Jeff Atwood (a co-founder of StackExchange) wrote about this, and in my experience he and other ...

0

This is a common theme: How can you help the uninformed / computer illiterate at the same time as showing information that more advanced users such as programmers, developer, testers, etc. can use. I think the answer is you do both! The order is important though and I recommend you have: What happened. What to do now Technical Details Technical ...

0

As you a writing a programming language, you should take advantage of the fact and make it mandatory to include an action for the devise by zero state. a <= n / c :0 div-by-zero-action I know what I've just suggested is essentially adding a 'goto' to your PL.

0

There are two fundamental reasons for a divide by zero. In a precise model (like integers), you get a divide by zero DBZ because the input is wrong. This is the kind of DBZ that most of us think of. In non-precise model (like floating pt), you might get a DBZ because of rounding-error even though the input is valid. This is what we don't normally think of. ...

2

IEEE 754 actually has a well defined solution for your problem. Exception handling without using exceptions http://en.wikipedia.org/wiki/IEEE_floating_point#Exception_handling 1/0 = Inf -1/0 = -Inf 0/0 = NaN this way all your operations make mathematically sense. \lim_{x \to 0} 1/x = Inf In my opinion following IEEE 754 makes the most sense since it ...

1

I liked the ternary operator where you provide an alternate value in case the denumerator is 0. One more idea I didn't see is to produce a general "invalid" value. A general "this variable doesn't have a value because the program did something bad", which carries a full stack trace with itself. Then, if you ever use that value anywhere, the result is again ...

2

I think the problem is " targeted at novice users. --> So there is no support for ..." Why are you thinking that exception handling is problematic for novice users? What is worse? Have a "difficult" feature or have no idea why something happened? What could confuse more? A crash with a core dump or "Fatal error: Divide by Zero"? Instead, I think is FAR ...

1

SQL, easily the language most widely used by non-programmers, does #3, for whatever that's worth. In my experience observing and assisting non-programmers writing SQL, this behavior is generally well understood and easily compensated for (with a case statement or the like). It helps that the error message you get tends to be quite direct e.g. in Postgres 9 ...

1

In my view your language should provide a generic mechanism for detecting and handling errors. Programming errors should be detected at compile time (or as early as possible) and should ordinarily lead to program termination. Errors that result from unexpected or erroneous data, or from unexpected external conditions, should be detected and made available ...

0

When designing an API for operations which may fail because of foreseeable reasons, but at unforeseeable times, one should generally allow a means by which callers can indicate whether they are expecting to cope with the semi-foreseeable failures. If the only methods which are available return with error codes rather than exceptions, then every call site ...

-1

The whole rows or an error status Consider returning the whole rows, at least as a run-time option. In DB inserts you may need to inspect the data that was inserted - since it often will be different from what you sent to the DB; common examples include autogenerated row IDs (that the app will likely immediately need), default values determined by DB, and ...

17

Another option is to return a result object instead of basic types. For example: OperationResult deleteResult = myOrm.deleteById(id); if (deleteResult.isSuccess()) { // .... } With this, if for some reason you need to return the numbers of rows affected, you simply can add a method in OperationResult: if (deleteResult.isSuccess()) { ...

10

I would not recommend any of them. Instead, return nothing (void) on success and throw an exception on failure.

2

"Is this better than that?" is not a useful question when the two alternatives don't do the same thing. If you need to know the affected row count, then you must use version A. If you don't have to, then you can use version B - but any advantage you might gain in terms of less code-writing effort is already gone since you took the trouble to post both ...

11

Returning the number of affected rows is better because it gives additional information about how the operation proceeded. No programmer will blame you because he/she has to write this to check if they got some changes during the operation: if(affectedRows > 0) { // success } else { // fail } but they will blame you when they'll have to know ...

1

I find Pete's answer very good and I would like to add some consideration and one example. A very interesting discussion regarding the use of exceptions versus returning special error values can be found in Programming in Standard ML, by Robert Harper, at the end of Section 29.3, page 243, 244. The problem is to implement a partial function f returning a ...

1

For a long time OO languages, the use of exceptions have been the de-facto standard for communicating errors. But functional programming languages provide the possibility of a different approach, e.g. using monads (which I have not been using), or the more lightweight "Railway Oriented Programming", as described by Scott Wlaschin. In this blog post In this ...

1

I have become a big fan of Checked Exceptions and I'd like to share my general rule on when to use them. I have come to the conclusion that there are basically 2 types of errors that my code has to deal with. There are errors that are testable before the code executes and there are errors that are non-testable before the code executes. A simple example ...

3

Neither. As others have pointed out, it is clearly not an IllegalStateException. And better than IllegalArgument would be FileNotFoundException or ParseException, (or maybe XMLParseException) which exactly match your description of "bad things" 1 and 2.

7

The Javadocs of IllegalStateException say Signals that a method has been invoked at an illegal or inappropriate time I would argue, that it does not matter when your method is called or in what state the JVM or your context is - the parsing error will remain as long as the file is not correct. So it seems to me, that an IllegalArgumentException is ...

Top 50 recent answers are included