Layers and exceptions
-
Let's say that you have this system with a data layer, a business rules layer and the UI layer. Let's say that one class of the data layer throws an exception under certain conditions. What would you rather do? A) Throw the exception and handle it in the business rules layer. B) Throw the exception and handle it in the UI layer. C) Handle the exception and return some error code to the BR layer. D) Other Usually I go for A, and the BR layer determines whether the user has to know about the error or not, and if so, display a message to the user. However, I am curious on what do CPians think about this.
Hope is the negation of reality - Raistlin Majere
-
Let's say that you have this system with a data layer, a business rules layer and the UI layer. Let's say that one class of the data layer throws an exception under certain conditions. What would you rather do? A) Throw the exception and handle it in the business rules layer. B) Throw the exception and handle it in the UI layer. C) Handle the exception and return some error code to the BR layer. D) Other Usually I go for A, and the BR layer determines whether the user has to know about the error or not, and if so, display a message to the user. However, I am curious on what do CPians think about this.
Hope is the negation of reality - Raistlin Majere
A or C, but I'd prefer C because I don't like exceptions being used for error handling. If it's an exception that the data layer can deal with then it shouldn't go beyond that layer. If it's an unrecoverable exception, not just an error, then it may be appropriate (re)throwing an exception for the BR layer to handle, so safe cleanup/termination/whatever can be done. Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
Let's say that you have this system with a data layer, a business rules layer and the UI layer. Let's say that one class of the data layer throws an exception under certain conditions. What would you rather do? A) Throw the exception and handle it in the business rules layer. B) Throw the exception and handle it in the UI layer. C) Handle the exception and return some error code to the BR layer. D) Other Usually I go for A, and the BR layer determines whether the user has to know about the error or not, and if so, display a message to the user. However, I am curious on what do CPians think about this.
Hope is the negation of reality - Raistlin Majere
Fernando A. Gomez F. wrote:
C) Handle the exception and return some error code to the BR layer.
Thou shall not mix exceptions and error codes.
Fernando A. Gomez F. wrote:
Usually I go for A, and the BR layer determines whether the user has to know about the error or not, and if so, display a message to the user. However, I am curious on what do CPians think about this.
Sounds ok imho, even with middle step wrapping exception and re-throwing for UI.
[My Blog]
"Visual studio desperately needs some performance improvements. It is sometimes almost as slow as eclipse." - Rüdiger Klaehn
"Real men use mspaint for writing code and notepad for designing graphics." - Anna-Jayne Metcalfe -
A or C, but I'd prefer C because I don't like exceptions being used for error handling. If it's an exception that the data layer can deal with then it shouldn't go beyond that layer. If it's an unrecoverable exception, not just an error, then it may be appropriate (re)throwing an exception for the BR layer to handle, so safe cleanup/termination/whatever can be done. Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
The problem with error codes is that your clients can ignore them.
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
-
Let's say that you have this system with a data layer, a business rules layer and the UI layer. Let's say that one class of the data layer throws an exception under certain conditions. What would you rather do? A) Throw the exception and handle it in the business rules layer. B) Throw the exception and handle it in the UI layer. C) Handle the exception and return some error code to the BR layer. D) Other Usually I go for A, and the BR layer determines whether the user has to know about the error or not, and if so, display a message to the user. However, I am curious on what do CPians think about this.
Hope is the negation of reality - Raistlin Majere
If i can and should do something about it in the data layer (retry / reconnect...), then do that. Otherwise, throw a specific exception to the next layer up. If i can do something about that exception in that layer (save/switch context, log it and continue with the next op) then i'll do so, otherwise i'll toss it up to the UI. By the time the UI sees it, it should be so critical that there's really no question as to what to do with it. I prefer that UIs only ever deal with two sorts of errors: critical (unable to do anything the user asked, call me and whine...) and non-critical (let the user know that something didn't work quite the way it should have, but we did our best: here's the result, and here's what you can do to make it work better next time). Exceptions are just dandy for the first sort... ;)
every night, i kneel at the foot of my bed and thank the Great Overseeing Politicians for protecting my freedoms by reducing their number, as if they were deer in a state park. -- Chris Losinger, Online Poker Players?
-
If i can and should do something about it in the data layer (retry / reconnect...), then do that. Otherwise, throw a specific exception to the next layer up. If i can do something about that exception in that layer (save/switch context, log it and continue with the next op) then i'll do so, otherwise i'll toss it up to the UI. By the time the UI sees it, it should be so critical that there's really no question as to what to do with it. I prefer that UIs only ever deal with two sorts of errors: critical (unable to do anything the user asked, call me and whine...) and non-critical (let the user know that something didn't work quite the way it should have, but we did our best: here's the result, and here's what you can do to make it work better next time). Exceptions are just dandy for the first sort... ;)
every night, i kneel at the foot of my bed and thank the Great Overseeing Politicians for protecting my freedoms by reducing their number, as if they were deer in a state park. -- Chris Losinger, Online Poker Players?
Right, each layer may be able to some subset of the Exceptions it encounters.
-
Fernando A. Gomez F. wrote:
C) Handle the exception and return some error code to the BR layer.
Thou shall not mix exceptions and error codes.
Fernando A. Gomez F. wrote:
Usually I go for A, and the BR layer determines whether the user has to know about the error or not, and if so, display a message to the user. However, I am curious on what do CPians think about this.
Sounds ok imho, even with middle step wrapping exception and re-throwing for UI.
[My Blog]
"Visual studio desperately needs some performance improvements. It is sometimes almost as slow as eclipse." - Rüdiger Klaehn
"Real men use mspaint for writing code and notepad for designing graphics." - Anna-Jayne Metcalfednh wrote:
Thou shall not mix exceptions and error codes.
:-D
Hope is the negation of reality - Raistlin Majere
-
Let's say that you have this system with a data layer, a business rules layer and the UI layer. Let's say that one class of the data layer throws an exception under certain conditions. What would you rather do? A) Throw the exception and handle it in the business rules layer. B) Throw the exception and handle it in the UI layer. C) Handle the exception and return some error code to the BR layer. D) Other Usually I go for A, and the BR layer determines whether the user has to know about the error or not, and if so, display a message to the user. However, I am curious on what do CPians think about this.
Hope is the negation of reality - Raistlin Majere
An exception should only be caught when something can be done with it. If it is a database deadlock for example, a retry might make sense, as long as it can be converted into an operation that is not an error. If it is less recoverable like a connection problem, then it should go up to the UI. The vast majority of exceptions should go up to the UI and be logged with an error message shown to the user. If it doesn't make sense for a specific exception, then that probably shouldn't have been an exception in the first place.
This blanket smells like ham
-
Let's say that you have this system with a data layer, a business rules layer and the UI layer. Let's say that one class of the data layer throws an exception under certain conditions. What would you rather do? A) Throw the exception and handle it in the business rules layer. B) Throw the exception and handle it in the UI layer. C) Handle the exception and return some error code to the BR layer. D) Other Usually I go for A, and the BR layer determines whether the user has to know about the error or not, and if so, display a message to the user. However, I am curious on what do CPians think about this.
Hope is the negation of reality - Raistlin Majere
Chuck Norris' code doesn't throw exceptions, it throws you! Marc
-
Chuck Norris' code doesn't throw exceptions, it throws you! Marc
:laugh: Oh, that'll explain many things... And I thought it was because of the beer...
Hope is the negation of reality - Raistlin Majere
-
Let's say that you have this system with a data layer, a business rules layer and the UI layer. Let's say that one class of the data layer throws an exception under certain conditions. What would you rather do? A) Throw the exception and handle it in the business rules layer. B) Throw the exception and handle it in the UI layer. C) Handle the exception and return some error code to the BR layer. D) Other Usually I go for A, and the BR layer determines whether the user has to know about the error or not, and if so, display a message to the user. However, I am curious on what do CPians think about this.
Hope is the negation of reality - Raistlin Majere
Generally you should handle the exception as close to the source as possible as long as it is meaningful to do so. By meaningful, this usually means that you need to do some sort of cleanup activity as a result of the exception to ensure that the internal state doesn't get corrupted or you cause memory leaks. You can also allow the exception to bubble up or wrap it in a more meaningful exception if it should bubble up to the calling code. Using error codes is definately not reccommended as the caller can simply ignore them. Using exceptions is the preferred method, but you shouldn't mix error codes and exceptions. If you feel you must use error codes, be consistent and use them throughout. Depending on how your application is architected (layered), the client will probably only need to know about a small number of exceptions.
Scott.
—In just two days, tomorrow will be yesterday. [Forum Guidelines] [Articles] [Blog]
-
If i can and should do something about it in the data layer (retry / reconnect...), then do that. Otherwise, throw a specific exception to the next layer up. If i can do something about that exception in that layer (save/switch context, log it and continue with the next op) then i'll do so, otherwise i'll toss it up to the UI. By the time the UI sees it, it should be so critical that there's really no question as to what to do with it. I prefer that UIs only ever deal with two sorts of errors: critical (unable to do anything the user asked, call me and whine...) and non-critical (let the user know that something didn't work quite the way it should have, but we did our best: here's the result, and here's what you can do to make it work better next time). Exceptions are just dandy for the first sort... ;)
every night, i kneel at the foot of my bed and thank the Great Overseeing Politicians for protecting my freedoms by reducing their number, as if they were deer in a state park. -- Chris Losinger, Online Poker Players?
Shog9 wrote:
I prefer that UIs only ever deal with two sorts of errors: critical ... and non-critical
:cool:
-
Shog9 wrote:
I prefer that UIs only ever deal with two sorts of errors: critical ... and non-critical
:cool:
Would you prefer "critical" and "downright abusive"?
-
Let's say that you have this system with a data layer, a business rules layer and the UI layer. Let's say that one class of the data layer throws an exception under certain conditions. What would you rather do? A) Throw the exception and handle it in the business rules layer. B) Throw the exception and handle it in the UI layer. C) Handle the exception and return some error code to the BR layer. D) Other Usually I go for A, and the BR layer determines whether the user has to know about the error or not, and if so, display a message to the user. However, I am curious on what do CPians think about this.
Hope is the negation of reality - Raistlin Majere
A, mostly.
Cheers, विक्रम
And sleep will come, it comes to us all And some will fade and some will fall
-
Let's say that you have this system with a data layer, a business rules layer and the UI layer. Let's say that one class of the data layer throws an exception under certain conditions. What would you rather do? A) Throw the exception and handle it in the business rules layer. B) Throw the exception and handle it in the UI layer. C) Handle the exception and return some error code to the BR layer. D) Other Usually I go for A, and the BR layer determines whether the user has to know about the error or not, and if so, display a message to the user. However, I am curious on what do CPians think about this.
Hope is the negation of reality - Raistlin Majere
I would also go for A. Cheers
You have the thought that modern physics just relay on assumptions, that somehow depends on a smile of a cat, which isn’t there.( Albert Einstein)
-
Let's say that you have this system with a data layer, a business rules layer and the UI layer. Let's say that one class of the data layer throws an exception under certain conditions. What would you rather do? A) Throw the exception and handle it in the business rules layer. B) Throw the exception and handle it in the UI layer. C) Handle the exception and return some error code to the BR layer. D) Other Usually I go for A, and the BR layer determines whether the user has to know about the error or not, and if so, display a message to the user. However, I am curious on what do CPians think about this.
Hope is the negation of reality - Raistlin Majere
Hi, I think each layer must handle the exceptions and errors and only inform upper layers about the problems.To accomplish this you have to return error codes to the upper layers.That is exactly what i do and as the program goes on, error codes increase.At higher layers we decide what to do, according to the error codes.It worked for me very well and i use it in every project. Thanks Behzad
behzad
-
Would you prefer "critical" and "downright abusive"?
Critical Downright abusive Mildly offensive Judgmental Gently informative Gender-neutral, grain-fed, free range, and cruelty free Politically correct ...
Software Zen:
delete this; -
Let's say that you have this system with a data layer, a business rules layer and the UI layer. Let's say that one class of the data layer throws an exception under certain conditions. What would you rather do? A) Throw the exception and handle it in the business rules layer. B) Throw the exception and handle it in the UI layer. C) Handle the exception and return some error code to the BR layer. D) Other Usually I go for A, and the BR layer determines whether the user has to know about the error or not, and if so, display a message to the user. However, I am curious on what do CPians think about this.
Hope is the negation of reality - Raistlin Majere
Everyone has a favorite way to architect an application. My design philosophy is different from yours which is different from Joe Cool's down the street. Personally I believe exceptions should be thrown and handled by the layer that makes the most sense. If the user is entering data into an interactive application, and an exception is thrown in the data layer, the exception should percolate back to the user if it is something that the user could fix. This way he knows how to fix the problem, and let you know you should have figured out a way to better validate data before the record/s got send to the database. If application is non interactive, a batch job say, let the database handle it by logging the error, and putting the troublesome record to the side, either storing it in a temp table or a file and then going on to complete the rest of the processes. In most cases there is no need to propagate exception outside the layer in which they occurred. SELECT * FROM users WHERE clue > 0 No rows returned
-
Let's say that you have this system with a data layer, a business rules layer and the UI layer. Let's say that one class of the data layer throws an exception under certain conditions. What would you rather do? A) Throw the exception and handle it in the business rules layer. B) Throw the exception and handle it in the UI layer. C) Handle the exception and return some error code to the BR layer. D) Other Usually I go for A, and the BR layer determines whether the user has to know about the error or not, and if so, display a message to the user. However, I am curious on what do CPians think about this.
Hope is the negation of reality - Raistlin Majere
I write this type of software all the time. What I've found works best is to handle exceptions as close as possible to where they occurred, if nothing productive can be done then it bubbles up to the next layer etc. Anything major will end up at the UI layer and is reported to the user and logged if it couldn't be handled below. By handled I mean complete whatever the users intent was. To say that errors shouldn't be passed up through exceptions is a bullshit rule when it comes to multilayered business apps that often have bits running through remoting. There is just no other way in many cases to deal with an error. What I think people should actually do is avoid exceptions in areas where they are generated as a result of user input. Instead there should be a business rules scheme in place to alert the user at the UI level (I use those blinky exclamation mark with mouseover text) if something they have entered isn't going to fly. For example the user should never see an exception error for anything that breaks a database schema rule, instead the UI should alert them to this problem and not allow them to attempt a database update until it's resolved. If a field is required that needs to be enforced at the UI level, other things may involve the help of business rules at the business object level etc. Often the code I write involves duplication of business rules at the UI level, the business object level and the database level. The reason for this is that my apps are often also developers API's at the business object level and there is also many users who think it's perfectly ok to just go in and play with the database directly.
Cum catapultae proscriptae erunt tum soli proscripti catapultas habebunt
-
Let's say that you have this system with a data layer, a business rules layer and the UI layer. Let's say that one class of the data layer throws an exception under certain conditions. What would you rather do? A) Throw the exception and handle it in the business rules layer. B) Throw the exception and handle it in the UI layer. C) Handle the exception and return some error code to the BR layer. D) Other Usually I go for A, and the BR layer determines whether the user has to know about the error or not, and if so, display a message to the user. However, I am curious on what do CPians think about this.
Hope is the negation of reality - Raistlin Majere
I hate programmers that swalllow exceptions in low-level layers (like database access libraries) just because they are afraid to throw it back up because it might crash their application. I have spent numerous hours debugging applications, just to later find out that another programmer coded the lower-level library to swallow the exception, because it was "safer". I insist that any low level layers like utilites and database layers must (1) catch the exception (2) log it in a file or notify via email and (3) throw it back up. Let the business layer handle it and decide whether to notify the client. And most times I will place the exception message somewhere at the end of the custom error message back to the client. This has saved me countless hours of debugging, because instead of getting an generic error message, I get the real problem, which might come 20 calls deep down from a lower-level library. And sometimes, you need to just throw the exception back up always. For instance, you have a webmethod in a webservice, that returns an array of strings or a custom object. This webmethod might call many other libraries, business objects, database objects, etc. If there is an error, you do not have much error handling to work with, you have to return the array of strings or the custom object. Therefore just throw the exception and let the consumer of the webmethod deal with it. We all know that exception handling is a very expensive transaction and should not be over-used or abused. But being afraid of exceptions because they crash your application is a much worse approach.