IMHO if you always functions that have a boolean result and an output
message parameter, you do not uses the power of Exceptions.
Depends, depends... but you can use some public methods with boolean
results but the private methods raises an exception if something was
broken, then you catch the exception - that you know what this is
because this is your code - and returns True/False in the public
method.
This is another opinion and I'll not argue against it. It's simply a
different view of mine. Anyway. When dealing with data, that's what I
basically do in a DM, all components I use are supposed to work with
exceptions. That's why all lines calling component methods or properties
which could potentially raise an exception are enclosed in my own
try...except blocks. Those blocks are there to avoid the program to
crash whithout letting the user know what's going on as far as the
presentation layer does its own work.
In a normal run, I'm not interested at all on which piece of code fails,
I just want to know that somethig failed and why. Using the more or less
explicit exception message most of the time it is fair enough to inform
the user (who then in turn will take developper's advice)
In many cases I have an Exception type for each unit and one for each
class that inherited from this global type unit.
I do this sometimes too. But only when the exception type is a means of
warning the presentation layer that a special situation araised. And I
can then modulate the exception message in a more convenient way.
Marcos Douglas
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
