New answers tagged

2

I think the most interesting difference between the two, certainly from the perspective of a language designer, is that Haskell's error handling is not a language feature but is part of the library, and yet it manages to be just as expressive and easy to work with as Java's. The reason that this works so nicely is due to Haskell's widespread use of Monads, ...


1

No. Others have noted that you may perhaps want to show users all exceptions in a nice dialog, or save them to a log. These are not terribly bad ideas. But what happens when the exception is a StackOverflowException? An OutOfMemoryException? You may even get a ClrException! In essence, you simply can't catch them all. You can try, and it may even provide ...


8

Yes. Anytime exceptions could be exposed to end users or external systems, it might be a good idea to catch all possible exceptions, perform some generic handling (like logging) and emit a generic message. Both for usability reasons and for security reasons (an exception might contain sensitive information). But often this top-level exception handler would ...


1

Yes. At the very least, it's justifiable on the client side for applications that serve non-technical users, provided you're giving the user meaningful instructions. For example, "There was an internal error. Please reload the page." Exceptions should always and only be caught at the point that something meaningful can be done to correct the problem.


3

Why does the administrator need to know the new password? 2) is actually only a problem if the administrator provides a new password, but not if the temporary password is randomly assigned and communicated to the user by a medium which the administrator can not eavesdrop. Don't let the administrator select the password, and he can no longer get any ...


1

Catching Exception is usually the wrong thing to do, however there are cases where it is acceptable and the right thing to do. When writing web APIs, you might not want to reveal too much information about exceptions to your clients. You may also have designed into your API an error indicator so that clients can use this to decide what to do next. In this ...


2

Pokemon exceptions ... Ever acceptable? Never say (N)ever, but here goes. A concise conceptualization of exceptions shows why. A try block tells me what situations I choose to not handle Where to try, catch, and after-the-fact handle exceptions is a design issue. Focused try blocks convey the program's concerns. Unreliable connections, undefined ...


2

Why you don't make an exception for 2? I mean, if the administrator sets a new password, it doesn't do the verification process of the old passwords. Just sets the new password and flags it so it needs to be changed at next logon. That way you can be sure the administrator has no access to the historical password file. There is a small risk for the ...


1

a business requirement [...] stipulates that a user is not allowed to reuse a previous password. The user cannot reuse her own previous password, but it doesn't prevent a user to reuse a password of somebody else, isn't it? I mean, if Jack and Mary are changing their passwords and Jack types the previous password of Mary, it shouldn't return a error, ...


4

I've implemented and used a "forgiving" API similar to what you're describing. But, it was forgiving only for read-type operations. And the reason was pretty simple: The underlying API (MySQL) was forgiving. If you connect to a MySQL database, for instance, you might think the only "valid" way to select a record by it's INT PK is to give it an INT: ...


4

For this service call, one might want to implement verbose logging. I assume there is various error handling in place. When an error occurs or null is returned, log everything in the request to and response back. Typically this type of information would go into a debug log, but for this case, I would promote it to your regular logging. Then, you can ...


2

Don't you want to abstract out this functionality ? e.g. you may want to log to a file, to a network socket, to stdout etc. I certainly don't think that your classes should know about files etc. but about an abstract logger, and you can decide later how this is going to work. This is a very common requirement, and you'll find libraries already exist to do ...



Top 50 recent answers are included