A very basic question about the way exceptions are integrated with the GUI.

Itay

17y3.9kSoftware Architecture/Engineering

Hi,
Let say I have a large input form, and in it I have a start date (SD) and an end date (ED) of something. Of course, SD must not be smaller than ED, and of course I take care of it somewhere in my classes (the logic level). [and throw exception if, indeed, SD < ED]
Now the question is how do I tell this (that ED must not be smaller than SD) to my end user?
Should I just check in the GUI whether SD < ED, let the end-user know by a simple message box, but create a very ugly duality of code? (consider that the checking can be MUCH more complicated than SD < ED, this just an example)

Or should I write some static method in the logic class that check (with the needed input) this (whether SD < ED), and use this method in the logic class itself, and in the GUI, but still creating a duality of checking? (this method will be used twice unnecessarily, in the GUI, and once again right after it in the logic class)

Or should I assume the input is okay, but surrounding the pertinent code with a try block, and (in the catch section) expose to the end user, with a message box, the exception, which contains parameters names, terms (etc.) he does not understand, and generally was not intent to him?

Or maybe I should catch the exception and just let the user know that SOMETHING isn't right and pray he will understand what the hell I'm talking about? (imagine a very loaded input form, and a indecipherable message that tells you that something is wrong)

Another option is to create a new kind of exception just for this very specific error (I might create a 1000 different exceptions classes that way).

Or maybe to throw a normal exception, and in the GUI comparing the message string error, to messages I know that might be thrown, and that way to determined what to tell the user.

As I see it, it should be a very basic question, because you're bumping into this situation in almost every application, so I'm quite sure there is some convention about what should be done. Would be glad to hear it :)

6 Replies

Know the answer? Post it — somebody with the same question will find it here.

Itay17y ago
i know how to handle exceptions.
ok so do say that the way i'll know the input is not validate is by catching the exceptions of my classes? (assume the input is alright and surrounding it by try block)..? that brings up two questions..

1) doesn't catching exceptions all the time is very slow?
2) how would the user know what exactly is the problem..?
0
Mahesh Chand17y ago
I would put exception code in a class for checking a valid business logic and if fails, throw an exception and UI should catch it. Read documentation on throwing exceptions.
0
Itay17y ago
ive replyed here already.. i guess it was deleted some why :S

errrrrr anyway.. the truth is im writing the whole project alone, but i prefer to to write everything as a component, even if it's not very likely to ever be used again.

so what should i do?

thanks a lot, itay.

p.s
are you people really able to design a class that doesn't validate its input, and just counting on the UI? sound difficult to me.. (not practilly
of course, but mentally).
0
Mahesh Chand17y ago
Are you building this class as a component? If YES, I agree.

If your class is a part of an n-tier development, there is no need to check. You just make sure your UI takes care of. This is a part of UI data validation. If data is not valid, I would not even go any further and restrict user right there. If you put all checks in your business logic classes, you may make your application execution slow b/c for every check, UI has to call classes and capture the exceptions.

If it's a Web application, I try not to execute any code if there is a problem in UI data entry and let the user know right away. If you put that logic in your business logic code that will run on the server, it may take a while until the user sees an error message and how proper it is.

It all depends on what kind of developer role you have. If you are an Architect, who sees the entire project (all layers) as an application, then check should be in UI. If you are a UI developer, check should be in UI. If you are a component developer, check should be in your Classes. If you are a DBA, check should be in your SP logic.

Hope it helps.
0
Itay17y ago
So are you saying I should allow to do something like this: [MyClass=the class with SD and ED]
new MyClass(new DateTime(2009,1,1), new DateTime(2008,1,1));

when the first parameter is SD and second is the ED?

that doesn't make any sense at all.. it's as though you could do:
new DateTime(2005,5,35)

I think the class should never allow illegal data... (especially if the class also calculate things.. which is quite common, is it not?)
0
Mahesh Chand17y ago
This logic SD
0